PEMBUATAN KAKAS BANTU UNTUK MENDETEKSI KETIDAKSESUAIAN DIAGRAM URUTAN (SEQUENCE DIAGRAM) DENGAN DIAGRAM KASUS PENGGUNAAN (USE CASE DIAGRAM)

TUGAS AKHIR - KI141502

PEMBUATAN KAKAS BANTU UNTUK MENDETEKSI KETIDAKSESUAIAN DIAGRAM URUTAN (SEQUENCE DIAGRAM) DENGAN DIAGRAM KASUS PENGGUNAAN (USE CASE DIAGRAM)

ANDRIAS MEISYAL YUWANTOKO NRP 5112100116 Dosen Pembimbing I Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng. Dosen Pembimbing II Adhatus Solichah Ahmadiyah, S.Kom., M.Sc. JURUSAN TEKNIK INFORMATIKA Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember Surabaya, 2017

TUGAS AKHIR - KI141502

PEMBUATAN KAKAS BANTU UNTUK MENDETEKSI KETIDAKSESUAIAN DIAGRAM URUTAN (SEQUENCE DIAGRAM) DENGAN DIAGRAM KASUS PENGGUNAAN (USE CASE DIAGRAM)

ANDRIAS MEISYAL YUWANTOKO NRP 5112100116 Dosen Pembimbing I Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng. Dosen Pembimbing II Adhatus Solichah Ahmadiyah, S.Kom., M.Sc. JURUSAN TEKNIK INFORMATIKA Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember Surabaya, 2017

Halaman ini sengaja dikosongkan

ii

UNDERGRADUATE THESIS - KI141502

A CASE TOOL FOR DETECTING INCONSISTENCY BETWEEN SEQUENCE DIAGRAM AND USE CASE DIAGRAM

ANDRIAS MEISYAL YUWANTOKO NRP 5112100116 Supervisor I Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng. Supervisor II Adhatus Solichah Ahmadiyah, S.Kom., M.Sc. DEPARTMENT OF INFORMATICS Faculty of Information Technology Institut Teknologi Sepuluh Nopember Surabaya, 2017


iv


vi

PEMBUATAN KAKAS BANTU UNTUK MENDETEKSI KETIDAKSESUAIAN DIAGRAM URUTAN (SEQUENCE DIAGRAM) DENGAN DIAGRAM KASUS PENGGUNAAN (USE CASE DIAGRAM) Nama NRP Jurusan Pembimbing I Pembimbing II

: : : : :

ANDRIAS MEISYAL YUWANTOKO 5112100116 Teknik Informatika FTIf -ITS Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng. Adhatus Solichah Ahmadiyah, S.Kom., M.Sc. Abstrak

Siklus hidup pengembangan perangkat lunak membagi aktivitas pengembangan ke dalam tahap merencanakan, menganalisis, merancang, mengimplementasikan, dan merawat perangkat lunak. Analis sistem memiliki peranan penting untuk menganalisis kebutuhan pengguna. Dalam pengembangan perangkat lunak berorientasi objek, analisis dan perancangan sistem mengacu kepada bahasa unified modeling language (UML). Analis sistem menerjemahkan kebutuhan tersebut dengan merancang diagram UML. Salah satu diagram yang dirancang adalah diagram urutan (sequence diagram). Sebuah diagram urutan dibuat berdasarkan skenario yang ada pada deskripsi kasus penggunaan (use case description). Skenario ditunjukkan dalam bentuk urutan alur interaksi antara aktor dan sistem. Analis sistem perlu memeriksa rancangan diagram urutan apabila ditemukan ketidaksesuaian. Ketidaksesuaian didefinisikan apakan urutan alur pada deskripsi kasus penggunaan sudah sesuai dengan urutan pesan yang dikirim oleh aktor ke kelas boundary atau sistem ke kelas boundary pada diagram urutan. Rancangan diagram yang sesuai berpengaruh kepada ketepatan (correctness) implementasi perangkat lunak. Namun, pemeriksaan ketidaksesuvii

aian masih dilakukan secara manual. Hal ini menjadi masalah apabila sebuah proyek perangkat lunak memiliki banyak rancangan diagram, tetapi sumber daya analis sistem tidak mencukupi. Analis sistem membutuhkan waktu yang lama untuk memeriksa rancangan diagram. Pembuatan kakas bantu untuk mendeteksi ketidaksesuaian kedua diagram tersebut sangat diperlukan. Kakas bantu yang dibuat mengimplementasikan pemrosesan bahasa alami. Pemrosesan bahasa alami yang digunakan adalah perhitungan kemiripan semantik kalimat. Pendeteksian ketidaksesuaian dilakukan dengan melakukan ekstraksi kalimat alur kejadian pada deskripsi kasus penggunaan dan triplet yang berisi aktor, message, boundary class atau boundary class, message, control class pada diagram urutan. Ketidaksesuaian dilihat dari nilai perhitungan kemiripan kalimat antara kalimat alur kejadian dan triplet yang melewati ambang batas yang telah ditentukan. Hasil pendeteksian dinyatakan dalam sebuah daftar yang berisi kalimat alur kejadian dan triplet dengan penanda “Sesuai” atau “Tidak sesuai”. Dari hasil percobaan, kakas bantu yang dibuat dapat mendeteksi ketidaksesuaian antara diagram urutan dan diagram kasus penggunaan. Nilai kesepakatan hasil deteksi ketidaksesuaian dengan ahli rekayasa perangkat lunak melalui kappa statistic didapatkan sejumlah 0,85. Sehingga dari hasil tersebut, kakas bantu ini diharapkan tidak hanya membantu analis sistem menghasilkan rancangan diagram yang sesuai akan tetapi mempercepat waktu pengembangan perangkat lunak. Kata kunci: diagram urutan, diagram kasus penggunaan, ketidaksesuaian, pemrosesan bahasa alami, kemiripan semantik kalimat.

viii

A CASE TOOL FOR DETECTING INCONSISTENCY BETWEEN SEQUENCE DIAGRAM AND USE CASE DIAGRAM Name NRP Major Supervisor I Supervisor II

: : : : :

ANDRIAS MEISYAL YUWANTOKO 5112100116 Informatics FTIf -ITS Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng. Adhatus Solichah Ahmadiyah, S.Kom., M.Sc. Abstract

Software development life cycle divides the development activities into planning, analysis, design, implementation, and maintenance phases. System analyst has an important role to analyze the user needs. In object-oriented software development, system analysis and design refers to the unified modeling language (UML). System analyst translates those requirements to UML diagrams. One of the UML diagrams is a sequence diagram. A sequence diagram is created based on scenario in the use case description. Scenarios are shown in the form of flow of interaction between actor and system. System analyst needs to examine draft of sequence diagram if inconsistency is found. Inconsistency is defined whether flows of interaction in the use case description are in accordance with the sequence of messages sent by actor to boundary class or system to boundary class. Ensuring consistency of diagram gives impact to correct implementation of system. However, this examination is still done manually. Problems arise if a project has a lot of diagrams, but the number of system analysts are insufficient. System analyst takes a long time to examine a draft of diagrams. Developing a computer-aided software engineering (CASE) tool that can detect inconsistency between sequence diagram and use

ix

case diagram is needed by system analyst. This tool implemented natural language processing. Natural language processing that was used on this research is sentence semantic similarity. Detection is done by extracting flow of events in the use case description and triplets that contains actor, message, boundary class or boundary class, message, control class in the sequence diagram. Inconsistency is detected from the calculation of sentence similarity between a flow of events and a triplet that exceeded preset threshold. Detection results are represented in a list that contains flow of events and triplets with “Sesuai” or “Tidak sesuai” as a label. From the experimental result, this tool can detect inconsistency between sequence diagram and use case diagram. The inconsistency detection result agreement with domain expert through kappa statistic obtained 0,85. Thus, this tool is expected to help not only for producing the appropriate design of diagrams but also speeding up software development. Keywords: sequence diagram, use case diagram, inconsistency, natural language processing, sentence semantic similarity.

x

KATA PENGANTAR

Õæk QË @ á Ô g QË @

é<Ë @ Õæ.

Alhamdulillahirabbil’alamin, segala puji bagi Allah SWT yang telah melimpahkan rahmat dan hidayah-Nya sehingga penulis dapat menyelesaikan Tugas Akhir yang berjudul “Pembuatan Kakas Bantu untuk Mendeteksi Ketidaksesuaian Diagram (Sequence Diagram) dengan Diagram Kasus Penggunaan (Use Case Diagram)”. Tugas Akhir ini disusun sebagai persyaratan untuk menyelesaikan Program Sarjana (S1) Jurusan Teknik Informatika Institut Teknologi Sepuluh Nopember Surabaya. Tugas Akhir ini dapat selesai tidak lepas dari bantuan dan dukungan beberapa pihak. Pada kesempatan ini, penulis mengucapkan terima kasih kepada: 1. Bapak Suwanto dan Ibu Yatimah selaku kedua orang tua serta keluarga penulis yang telah memberikan doa dan dukungan baik moral maupun material yang tak terhingga. 2. Bapak Daniel Oranova Siahaan, S.Kom., M.Sc, P.D.Eng., selaku pembimbing I yang telah meluangkan waktu untuk membantu, membimbing, dan memotivasi penulis dalam menyelesaikan Tugas Akhir. 3. Ibu Adhatus Solichah Ahmadiyah, S.Kom., M.Sc., selaku pembimbing II yang juga telah meluangkan waktu untuk membantu, membimbing, dan memotivasi penulis dalam menyelesaikan Tugas Akhir. 4. Bapak Prof. Dr. Ir. Joko Lianto Buliali selaku dosen wali yang telah memberikan arahan dan nasihat selama penulis kuliah di Teknik Informatika ITS. 5. Bapak Darlis Herumurti, S.Kom., M.Kom., selaku kepala jurusan Teknik Informatika ITS, segenap dosen Teknik Informatika ITS yang telah memberikan ilmunya selama penulis kuliah di Teknik Informatika ITS, dan seluruh staf dan karyawan Teknik Informatika ITS yang telah membantu selama penulis kuliah di xi

Teknik Informatika ITS. 6. Teman-teman angkatan 2012 yang telah membantu, membagikan ilmu, menjaga kebersamaan, dan memberikan motivasi kepada penulis. 7. Serta pihak lainnya yang tidak bisa disebutkan satu per satu, yang telah turut membantu penulis dalam menyelesaikan Tugas Akhir ini. Penulis menyadari bahwa Tugas Akhir ini masih memiliki banyak kekurangan. Oleh sebab itu, dengan kerendahan hati, penulis mengharapkan kritik dan saran dari pembaca untuk perbaikan ke depan. Surabaya, Januari 2017 Andrias Meisyal Yuwantoko

xii

DAFTAR ISI

ABSTRAK

vii

ABSTRACT

ix

KATA PENGANTAR

xi

DAFTAR ISI

xiii

DAFTAR TABEL

xix

DAFTAR GAMBAR

xxiii

DAFTAR KODE SUMBER

xxvii

BAB I 1.1 1.2 1.3 1.4 1.5 1.6 1.7

PENDAHULUAN Latar Belakang . . . . . . . . . . . . . . . Rumusan Masalah . . . . . . . . . . . . . . Batasan Masalah . . . . . . . . . . . . . . Tujuan . . . . . . . . . . . . . . . . . . . . Manfaat . . . . . . . . . . . . . . . . . . . Metodologi . . . . . . . . . . . . . . . . . Sistematika Penulisan Laporan Tugas Akhir

BAB II 2.1 2.2 2.3 2.4

TINJAUAN PUSTAKA Diagram Kasus Penggunaan (Use Case Diagram) . Deskripsi Kasus Penggunaan (Use Case Description) Diagram Urutan (Sequence Diagram) . . . . . . . Ketidaksesuaian Diagram Urutan dan Diagram Kasus Penggunaan . . . . . . . . . . . . . . . . . . . XML Metadata Interchange (XMI) . . . . . . . . . StarUML . . . . . . . . . . . . . . . . . . . . . . Pemrosesan Bahasa Alami (Natural Language Processing) . . . . . . . . . . . . . . . . . . . . . . .

2.5 2.6 2.7

xiii

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

1 1 3 3 4 4 4 7 11 11 14 16 20 21 27 28

2.8

Perhitungan Kemiripan Kalimat . . . . . . . . . . 2.8.1 Kemiripan Semantik Kalimat (Sentence Semantic Similarity) . . . . . . . . . . . . . . 2.8.2 Kemiripan Sintaksis Kalimat (Word Order Similarity) . . . . . . . . . . . . . . . . . 2.8.3 Kombinasi Semantik dan Sintaksis Kalimat 2.9 WordNet . . . . . . . . . . . . . . . . . . . . . . . 2.10 Perhitungan Kemiripan Kata . . . . . . . . . . . . 2.10.1 Leacock-Chodorow . . . . . . . . . . . . . 2.10.2 Wu-Palmer . . . . . . . . . . . . . . . . . 2.10.3 Path . . . . . . . . . . . . . . . . . . . . . 2.10.4 Resnik . . . . . . . . . . . . . . . . . . . . 2.10.5 Lin . . . . . . . . . . . . . . . . . . . . . 2.10.6 Jiang-Conrath . . . . . . . . . . . . . . . BAB III ANALISIS DAN PERANCANGAN SISTEM 3.1 Analisis Perangkat Lunak . . . . . . . . . . . . . . 3.1.1 Deskripsi Umum Perangkat Lunak . . . . . 3.1.2 Proses Bisnis . . . . . . . . . . . . . . . . 3.1.3 Fungsi Produk . . . . . . . . . . . . . . . 3.1.4 Karakteristik Pengguna . . . . . . . . . . . 3.1.5 Batasan . . . . . . . . . . . . . . . . . . . 3.1.6 Kebutuhan Non-fungsional . . . . . . . . . 3.1.7 Diagram Kasus Penggunaan . . . . . . . . 3.1.8 Diagram Aktivitas (Activity Diagram) . . . 3.1.8.1 Diagram Aktivitas: Memeriksa Ketidaksesuaian Dokumen Rancangan . . . . . . . . . . . . . . . . 3.1.8.2 Diagram Aktivitas: Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian . . . . . . . . . . . 3.1.9 Kelas Analisis . . . . . . . . . . . . . . . xiv

34 35 37 38 38 39 41 41 41 42 42 42 45 45 45 46 47 47 48 48 49 51

52

53 54

3.1.9.1

3.2

Kelas Analisis Memeriksa Ketidaksesuaian Dokumen Rancangan 54 3.1.9.2 Kelas Analisis Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian . . . . . . . . . . . . . 73 3.1.10 Diagram Urutan . . . . . . . . . . . . . . 88 Perancangan Perangkat Lunak . . . . . . . . . . . 92 3.2.1 Perancangan Antarmuka . . . . . . . . . . 92 3.2.1.1 Antarmuka Utama . . . . . . . . 92 3.2.1.2 Jendela Masukan Berkas Dokumen Rancangan . . . . . . . . . 93 3.2.1.3 Antarmuka Ekspor Hasil Pemeriksaan ke dalam Laporan . . . . 95 3.2.1.4 Jendela Simpan Hasil . . . . . . 96 3.2.2 Perancangan Proses Kakas Bantu . . . . . 97 3.2.2.1 Proses Membuat Dokumen Rancangan . . . . . . . . . . . . . . 98 3.2.2.2 Proses Memasukkan Dokumen Rancangan . . . . . . . . . . . . . . 104 3.2.2.3 Proses Memilih Opsi Ekspor Hasil Deteksi Ketidaksesuaian . . . 105 3.2.2.4 Proses Mengekstraksi Dokumen Rancangan . . . . . . . . . . . . 106 3.2.2.5 Proses Mendeteksi Ketidaksesuaian . . . . . . . . . . . . . . . 115 3.2.2.6 Proses Menghitung Kemiripan Kalimat Alur Kejadian Dasar (Basic Flow) dan Triplet . . . . . . . . 118 3.2.2.7 Proses Menampilkan Hasil Deteksi Ketidaksesuaian . . . . . . . . 123 3.2.2.8 Proses Mengekspor Hasil Deteksi dalam Bentuk Laporan . . . . 123 3.2.3 Perancangan Diagram Kelas (Class Diagram)124 xv

3.2.3.1 3.2.3.2

3.2.3.3

Diagram Kelas Memeriksa Ketidaksesuaian Dokumen Rancangan 124 Diagram Kelas Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian . . . . . . . . . . . . . 149 Diagram Kelas Keseluruhan . . . 156

BAB IV IMPLEMENTASI SISTEM 159 4.1 Lingkungan Implementasi . . . . . . . . . . . . . 159 4.2 Detail Implementasi Kakas Bantu . . . . . . . . . 159 4.2.1 Implementasi Antarmuka . . . . . . . . . . 159 4.2.1.1 Implementasi Antarmuka Utama 160 4.2.1.2 Implementasi Jendela Masukan Berkas Dokumen Rancangan . . . . 161 4.2.1.3 Implementasi Antarmuka Ekspor Hasil Pemeriksaan ke dalam Laporan . . . . . . . . . . . . . . . 161 4.2.1.4 Implementasi Jendela Simpan Hasil162 4.2.2 Implementasi Proses . . . . . . . . . . . . 163 4.2.2.1 Implementasi Proses Mengekstraksi Dokumen Rancangan . . . . . 163 4.2.2.2 Implementasi Proses Mendeteksi Ketidaksesuaian . . . . . . . . . 165 4.2.2.3 Implementasi Proses Menghitung Kemiripan Kalimat Alur Kejadian Dasar (Basic Flow) dan Triplet 171 4.2.2.4 Implementasi Proses Menghitung Kemiripan Kata . . . . . . . . . 177 4.2.2.5 Implementasi Proses Mengekspor Hasil Deteksi dalam Bentuk Laporan . . . . . . . . . . . . . . . 180 BAB V PENGUJIAN DAN EVALUASI 187 5.1 Lingkungan Pengujian . . . . . . . . . . . . . . . 187 xvi

5.2 5.3

5.4

Data Pengujian . . . . . . . . . . . . . . . . . . . Skenario Pengujian . . . . . . . . . . . . . . . . . 5.3.1 Pengujian Hasil Deteksi Ketidaksesuaian . 5.3.1.1 Pengujian Hasil Deteksi Ketidaksesuaian Kakas Bantu Sesuai Teori Pembuatan Sequence Diagram 5.3.1.2 Pengujian Hasil Deteksi Ketidaksesuaian antara Kakas Bantu dan Ahli . . . . . . . . . . . . . . . 5.3.2 Pengujian Fungsional . . . . . . . . . . . . 5.3.2.1 Pengujian Fitur Memeriksa Ketidaksesuaian Dokumen Rancangan 5.3.2.2 Pengujian Fitur Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian . . . . . . . . . . . . . 5.3.3 Pengujian Non-fungsional . . . . . . . . . Evaluasi Pengujian . . . . . . . . . . . . . . . . . 5.4.1 Evaluasi Pengujian Hasil Deteksi Ketidaksesuaian . . . . . . . . . . . . . . . . . . . 5.4.2 Evaluasi Pengujian Fungsional . . . . . . . 5.4.3 Evaluasi Pengujian Non-fungsional . . . .

187 188 189

191

194 200 201

204 207 217 217 219 220

BAB VI KESIMPULAN DAN SARAN 223 6.1 Kesimpulan . . . . . . . . . . . . . . . . . . . . . 223 6.2 Saran . . . . . . . . . . . . . . . . . . . . . . . . 223 LAMPIRAN A NAAN

SPESIFIKASI KASUS PENGGU-

LAMPIRAN B

DATA PENGUJIAN

225 229

DAFTAR PUSTAKA

243

BIODATA PENULIS

247 xvii


xviii

DAFTAR TABEL

2.1 2.2 2.3 2.4 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

3.12 3.13 3.14 3.15 3.16

Komponen diagram kasus penggunaan . . . . . . . Komponen diagram urutan . . . . . . . . . . . . . Elemen penting XMI pada diagram kasus penggunaan dan diagram urutan . . . . . . . . . . . . . . Model Penn Treebank bahasa Inggris . . . . . . .

12 17 22 29

Kandidat kelas kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . . . . . . . 56 Pemetaan kandidat kelas kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . 66 Tanggung jawab kelas pada kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . 69 Atribut dan hubungan kelas pada kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” 72 Kandidat kelas kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” . . . . 75 Pemetaan kandidat kelas kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” 82 Tanggung jawab kelas pada kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” 85 Atribut dan hubungan kelas pada kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” . . . . . . . . . . . . . . . . . . . . . . 87 Spesifikasi atribut antarmuka utama kakas bantu . . 93 Spesifikasi atribut jendela masukan berkas dokumen rancangan . . . . . . . . . . . . . . . . . . . 94 Spesifikasi atribut antarmuka ekspor hasil pemeriksaan ke dalam laporan . . . . . . . . . . . . . . . . 95 Spesifikasi atribut jendela simpan hasil . . . . . . . 96 Pemetaan elemen diagram dengan elemen dokumen rancangan (XMI) . . . . . . . . . . . . . . . . . . 106 xix

3.17 Himpunan kata benda kalimat pertama dibanding ruang semantik kata benda . . . . . . . . . . . . . 3.18 Himpunan kata kerja kalimat pertama dibanding ruang semantik kata kerja . . . . . . . . . . . . . . . 3.19 Atribut dan operasi kelas pada proses memasukkan dokumen rancangan . . . . . . . . . . . . . . . . . 3.20 Atribut dan operasi kelas pada proses mengekstraksi dokumen rancangan . . . . . . . . . . . . . . . 3.21 Atribut dan operasi kelas pada proses mendeteksi ketidaksesuaian . . . . . . . . . . . . . . . . . . . 3.22 Atribut dan operasi kelas pada proses menghitung kemiripan kalimat alur kejadian dasar dan triplet . 3.23 Atribut dan operasi kelas pada proses menampilkan hasil deteksi ketidaksesuaian . . . . . . . . . . . . 3.24 Atribut dan operasi kelas pada proses memilih opsi ekspor hasil deteksi ketidaksesuaian . . . . . . . . 3.25 Atribut dan operasi kelas pada proses mengekspor hasil deteksi dalam bentuk laporan . . . . . . . . . 3.26 Modul-modul di dalam kakas bantu . . . . . . . . 5.1 5.2 5.3 5.4 5.5 5.6 5.7

121 121 125 128 136 143 145 151 153 156

Hasil sebuah percobaan . . . . . . . . . . . . . . . 189 Hasil deteksi ketidaksesuaian sistem “ARENA” antara kakas bantu dengan ahli pertama . . . . . . . . 195 Hasil deteksi ketidaksesuaian sistem “ARENA” antara kakas bantu dengan ahli kedua . . . . . . . . . 195 Hasil deteksi ketidaksesuaian sistem “ATM” antara kakas bantu dengan ahli pertama . . . . . . . . . . 196 Hasil deteksi ketidaksesuaian sistem “Simple Address Book” antara kakas bantu dengan ahli pertama . . . 197 Hasil deteksi ketidaksesuaian sistem “Simple Address Book” antara kakas bantu dengan ahli kedua . . . . 197 Hasil deteksi ketidaksesuaian sistem “Online Shopping System” antara kakas bantu dengan ahli pertama198 xx

5.8

5.9

5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22

Hasil deteksi ketidaksesuaian sistem “Emergency Monitoring System” antara kakas bantu dengan ahli pertama . . . . . . . . . . . . . . . . . . . . . . . 198 Hasil deteksi ketidaksesuaian sistem “Community Peace Program” antara kakas bantu dengan ahli pertama . . . . . . . . . . . . . . . . . . . . . . . . . 199 Nilai kappa statistic setiap kasus uji . . . . . . . . 200 Skenario pertama pengujian fitur memeriksa ketidaksesuaian dokumen rancangan . . . . . . . . . . 201 Skenario kedua pengujian fitur memeriksa ketidaksesuaian dokumen rancangan . . . . . . . . . . . . 203 Skenario pertama pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian . . . . . . 204 Skenario kedua pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian . . . . . . . . . 206 Hasil perhitungan kuesioner dalam bentuk pernyataan208 Hasil pengisian kuesioner untuk pertanyaan pertama 210 Hasil pengisian kuesioner untuk pertanyaan kedua . 211 Hasil pengisian kuesioner untuk pertanyaan ketiga . 212 Hasil pengisian kuesioner untuk pertanyaan keempat 214 Hasil pengisian kuesioner untuk pertanyaan kelima 214 Hasil pengujian fungsional . . . . . . . . . . . . . 219 Kategori nilai pernyataan usability . . . . . . . . . 220

xxi


xxii

DAFTAR GAMBAR

2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15

Contoh diagram kasus penggunaan . . . . . . . . . Contoh diagram urutan . . . . . . . . . . . . . . . Contoh deskripsi kasus penggunaan pada aplikasi StarUML 2 . . . . . . . . . . . . . . . . . . . . . Potongan hubungan semantik pada WordNet . . . . Metrik knowledge-based similarity . . . . . . . . .

11 16

Diagram kasus penggunaan kakas bantu . . . . . . Kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . . . . . . . . . . . . . . . . Diagram aktivitas kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . . . . . Diagram aktivitas kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” . . . Diagram urutan kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . . . . . . . Diagram urutan proses mendeteksi ketidaksesuaian Diagram urutan kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” . . . . Diagram urutan proses mengekspor hasil deteksi ke laporan . . . . . . . . . . . . . . . . . . . . . . . Arsitektur perangkat lunak . . . . . . . . . . . . . Struktur proyek dokumen rancangan pada aplikasi StarUML 2 . . . . . . . . . . . . . . . . . . . . . Diagram kasus penggunaan “Online Shopping System” . . . . . . . . . . . . . . . . . . . . . . . . . Alur dasar (basic flow) kasus penggunaan “Buy a Product” . . . . . . . . . . . . . . . . . . . . . . . Diagram urutan “Buy a Product” . . . . . . . . . . Contoh kelas (class) yang berinteraksi pada diagram urutan “Buy a Product” . . . . . . . . . . . . . . . Alur proses ekstraksi dokumen rancangan . . . . .

49

xxiii

27 39 40

50 52 53 89 90 91 92 98 99 100 100 103 111 114

3.16 Alur proses deteksi ketidaksesuaian . . . . . . . . 3.17 Alur menghitung kemiripan kalimat alur kejadian dasar kasus penggunaan dan triplet . . . . . . . . . 3.18 Kelas diagram proses memasukkan dokumen rancangan . . . . . . . . . . . . . . . . . . . . . . . . 3.19 Kelas diagram proses mengekstraksi dokumen rancangan . . . . . . . . . . . . . . . . . . . . . . . . 3.20 Kelas diagram proses mendeteksi ketidaksesuaian . 3.21 Kelas diagram proses menghitung kemiripan kalimat alur kejadian dasar dan triplet . . . . . . . . . 3.22 Kelas diagram proses menampilkan hasil deteksi ketidaksesuaian . . . . . . . . . . . . . . . . . . . . 3.23 Kelas diagram proses memilih opsi ekspor hasil deteksi ketidaksesuaian . . . . . . . . . . . . . . . . 3.24 Kelas diagram proses mengekspor hasil deteksi dalam bentuk laporan . . . . . . . . . . . . . . . . . 3.25 Diagram paket (package diagram) kakas bantu . . 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5

Hasil implementasi antarmuka utama kakas bantu . Hasil implementasi jendela “Masukan berkas dokumen rancangan” . . . . . . . . . . . . . . . . . . . Hasil implementasi antarmuka ekspor hasil pemeriksaan ke dalam laporan . . . . . . . . . . . . . . Hasil implementasi jendela ”Simpan hasil” . . . .

116 119 125 128 135 143 145 150 152 158 160 161 162 162

Diagram urutan “Upload Event Proposal” . . . . . 192 Hasil deteksi ketidaksesuaian kasus penggunaan “Upload Event Proposal” . . . . . . . . . . . . . . . . 192 Hasil deteksi ketidaksesuaian kasus penggunaan “Upload Event Proposal” (alur deskripsi terbalik) . . . 193 Hasil deteksi ketidaksesuaian kasus penggunaan “Upload Event Proposal” (salah satu alur deskripsi hilang)194 Hasil deteksi ketidaksesuaian pada antarmuka utama kakas bantu . . . . . . . . . . . . . . . . . . . 202 xxiv

5.6 5.7 5.8

Pesan kesalahan format berkas dokumen rancangan 204 Pesan kesalahan format berkas dokumen rancangan 206 Pesan kesalahan format berkas laporan hasil deteksi ketidaksesuaian . . . . . . . . . . . . . . . . . . . 207

A.1 Kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” . . . . . . . . . . . . . . . . . 225 B.1 Diagram kasus penggunaan ARENA “Announce Tournament” . . . . . . . . . . . . . . . . . . . . . . . 229 B.2 Diagram urutan ARENA “Announce Tournament” 230 B.3 Diagram kasus penggunaan ARENA “Chat with Players” . . . . . . . . . . . . . . . . . . . . . . . . . 230 B.4 Diagram urutan ARENA “Chat with Players” . . . 231 B.5 Diagram kasus penggunaan ARENA “Drop Item” . 231 B.6 Diagram urutan ARENA “Drop Item” . . . . . . . 232 B.7 Diagram kasus penggunaan ARENA “Look at Item” 232 B.8 Diagram urutan ARENA “Look at Item” . . . . . . 233 B.9 Diagram kasus penggunaan ARENA “Move” . . . 233 B.10 Diagram urutan ARENA “Move” . . . . . . . . . 234 B.11 Diagram kasus penggunaan ATM “System Startup” 234 B.12 Diagram urutan ATM “System Startup” . . . . . . 235 B.13 Diagram kasus penggunaan ATM “System Shutdown” . . . . . . . . . . . . . . . . . . . . . . . . . 235 B.14 Diagram urutan ATM “System Shutdown” . . . . . 236 B.15 Diagram kasus penggunaan Simple Address Book “Edit a Person” . . . . . . . . . . . . . . . . . . . 236 B.16 Diagram urutan Simple Address Book “Edit a Person”237 B.17 Diagram kasus penggunaan Simple Address Book “Sort Entries by Name” . . . . . . . . . . . . . . . 238 B.18 Diagram urutan Simple Address Book “Sort Entries by Name” . . . . . . . . . . . . . . . . . . . . . . 238 B.19 Diagram kasus penggunaan Online Shopping System “Make Order Request” . . . . . . . . . . . . . 239 xxv

B.20 Diagram urutan Online Shopping System “Make Order Request” . . . . . . . . . . . . . . . . . . . . . . . 239 B.21 Diagram kasus penggunaan Emergency Monitoring System “View Alarms” . . . . . . . . . . . . . . . 240 B.22 Diagram urutan Emergency Monitoring System “View Alarms” . . . . . . . . . . . . . . . . . . . . . . . 240 B.23 Diagram kasus penggunaan Community Peace Program “Disburse Payments” . . . . . . . . . . . . . 241 B.24 Diagram urutan Community Peace Progam “Disburse Payments” . . . . . . . . . . . . . . . . . . 241

xxvi

DAFTAR KODE SUMBER

3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14

Elemen diagram kasus penggunaan “Online Shopping System” dalam XMI . . . . . . . . . . . . . . Elemen deskripsi kasus penggunaan “Buy a Product” dalam XMI . . . . . . . . . . . . . . . . . . . Elemen judul diagram urutan “Buy a Product” dalam XMI . . . . . . . . . . . . . . . . . . . . . . . Elemen kelas sebuah diagram urutan dalam XMI . Elemen pesan (message) sebuah diagram urutan dalam XMI . . . . . . . . . . . . . . . . . . . . . . . Potongan kode fungsi mendeteksi ketidaksesuaian . Potongan kode fungsi mengekstraksi dokumen rancangan . . . . . . . . . . . . . . . . . . . . . . . . Potongan kode API dari SAX . . . . . . . . . . . . Potongan kode fungsi mengelompokkan nama kasus penggunaan (use case) . . . . . . . . . . . . . Potongan kode fungsi mendeteksi ketidaksesuaian . Potongan kode pre-processing triplet . . . . . . . . Potongan kode pre-processing kalimat . . . . . . . Potongan kode part-of-speech tagging dan lemmatization kalimat . . . . . . . . . . . . . . . . . . . Potongan kode pengelompokan kata benda dan kata kerja . . . . . . . . . . . . . . . . . . . . . . . . . Potongan kode perhitungan kemiripan ruang semantik kata benda dengan kata benda kalimat pertama . Potongan kode mendapatkan vektor kata benda kalimat pertama . . . . . . . . . . . . . . . . . . . . Potongan kode menghitung nilai cosine similarity kata benda . . . . . . . . . . . . . . . . . . . . . . Potongan kode menghitung nilai akhir kemiripan semantik kalimat . . . . . . . . . . . . . . . . . . Potongan kode fungsi menghitung kemiripan semantik kata dengan metrik Lin . . . . . . . . . . . . . xxvii

109 109 110 111 112 163 164 164 166 167 169 172 172 173 174 176 177 177 178

4.15 Potongan kode menyimpan hasil deteksi ketidaksesuaian . . . . . . . . . . . . . . . . . . . . . . . . 4.16 Potongan kode mengekspor hasil deteksi ketidaksesuaian ke bentuk laporan . . . . . . . . . . . . . . 4.17 Potongan kode mengolah kalimat alur kejadian dasar kasus penggunaan hasil deteksi ketidaksesuaian 4.18 Potongan kode mengolah triplet hasil deteksi ketidaksesuaian . . . . . . . . . . . . . . . . . . . . .

xxviii

180 182 183 184

BAB I PENDAHULUAN

Bab ini membahas hal yang mendasari dilakukannya pengerjaan Tugas Akhir ini dan identifikasi dari permasalahan yang akan diteliti.

1.1 Latar Belakang Daur hidup pengembangan perangkat lunak (software development life cycle) membagi aktivitas pengembangan ke dalam tahap merencanakan, menganalisis, merancang, mengimplementasikan, dan merawat perangkat lunak. Tahap pertama pengembangan perangkat lunak diawali dengan merencanakan proyek perangkat lunak. Kemudian, tahap berikutnya adalah tahap analisis. Seorang analis sistem memiliki peranan penting pada tahap ini untuk menganalisis dan mengembangkan kebutuhan pengguna ke dalam sebuah dokumen spesifikasi kebutuhan. Dokumen spesifikasi kebutuhan yang dihasilkan akan menjadi panduan pengembang untuk memahami dan menyelesaikan proyek perangkat lunak dengan baik. Dalam pengembangan perangkat lunak berbasis objek, analisis dan perancangan sistem mengacu kepada bahasa unified modeling language (UML) yang membantu kebutuhan perangkat lunak saling berkomunikasi [1]. Analis sistem menerjemahkan kebutuhan tersebut dengan merancang diagram UML. Salah satu diagram yang dirancang adalah diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram). Diagram kasus penggunaan menggambarkan aktor, kasus penggunaan (use case), dan interaksinya di dalam sistem. Interaksi tersebut dijelaskan ke dalam sebuah skenario dalam bentuk alur kejadian (flow of events) pada deskripsi kasus penggunaan (use case description). Deskripsi tersebut menjadi panduan untuk menyusun diagram urutan. Analis sistem menurunkan alur kejadian pada deskripsi kasus penggunaan menjadi kelas-kelas (class). Kelas-kelas ini nantinya berinteraksi di dalam 1

2 diagram urutan melalui serangkaian pesan (message). Analis sistem perlu memeriksa dan memperbaiki rancangan diagram apabila ditemukan ketidaksesuaian selama iterasi pengembangan. Ketidaksesuaian didefinisikan apakah urutan alur kejadian yang ada pada deskripsi kasus penggunaan sudah sesuai dengan urutan pesan yang dikirimkan oleh aktor ke kelas boundary atau sistem ke kelas boundary pada diagram urutan. Tujuan dari pemeriksaan ketidaksesuaian adalah melihat konsistensi logika interaksi antara diagram kasus penggunaan dan diagram urutan karena pada dasarnya diagram urutan merupakan realisasi dari skenario diagram kasus penggunaan. Rancangan diagram yang sesuai berpengaruh kepada ketepatan (correctness) implementasi perangkat lunak. Namun, pemeriksaan ketidaksesuaian ini masih dilakukan secara manual oleh analis sistem. Hal ini tidak menjadi masalah apabila rancangan diagram tidak banyak. Permasalahan muncul jika di sebuah proyek memiliki banyak rancangan diagram, tetapi sumber daya analis sistem tidak mencukupi. Analis sistem membutuhkan waktu yang lama untuk memeriksa rancangan diagram tersebut. Oleh sebab itu, pembuatan kakas bantu yang dapat mendeteksi ketidaksesuaian antara diagram urutan dengan diagram kasus penggunaan sangat diperlukan oleh analis sistem. Kakas bantu yang dibuat menerapkan pemrosesan bahasa alami (natural language processing). Pemrosesan bahasa alami yang digunakan adalah perhitungan kemiripan semantik kalimat. Pendeteksian ketidaksesuaian dilakukan dengan melakukan ekstraksi deskripsi kasus penggunaan dan diagram urutan dari dokumen rancangan. Untuk deskripsi kasus penggunaan, mengambil kalimat alur kejadian kasus penggunaan, sedangkan diagram urutan, mengambil triplet. Triplet terdiri dari nama aktor, message, boundary class atau nama control class, message, boundary class. Kemudian, menghitung kemiripan semantik antara kalimat alur kejadian kasus penggunaan dengan triplet. Perhitungan kemiripan semantik kalimat digunakan dalam pendeteksian karena adanya perbedaan bahasa pa-

3 da kalimat alur kejadian kasus penggunaan (menggunakan bahasa pengguna) dan triplet (menggunakan bahasa pengembang). Perbedaan ini terjadi saat analis sistem menurunkan kalimat alur kejadian kasus penggunaan ke dalam kelas-kelas selama tahap analisis. Contoh, kata “window” pada kalimat alur kejadian kasus penggunaan menjadi “GUI” pada triplet. Nilai kemiripan kalimat yang melewati ambang batas (threshold) yang telah ditentukan menjadi dasar penilaian ketidaksesuaian. Hasil pendeteksian dinyatakan dalam sebuah daftar yang berisi nama kasus penggunaan, kalimat alur kejadian kasus penggunaan, dan triplet dengan penanda “Sesuai” atau “Tidak sesuai”. Sehingga, pembuatan kakas bantu ini diharapkan tidak hanya membantu analis sistem menghasilkan rancangan diagram yang sesuai akan tetapi mempercepat waktu pengembangan perangkat lunak.

1.2 Rumusan Masalah Rumusan masalah yang diangkat dalam Tugas Akhir ini dipaparkan sebagai berikut: 1. Bagaimana mengekstraksi deskripsi kasus penggunaan dan diagram urutan dari dokumen rancangan? 2. Bagaimana menghitung kemiripan antara kalimat alur kejadian kasus penggunaan pada deksripsi kasus penggunaan dengan triplet pada diagram urutan? 3. Bagaimana membangun kakas bantu yang dapat mendeteksi ketidaksesuaian antara diagram urutan dan diagram kasus penggunaan?

1.3 Batasan Masalah Permasalahan yang dibahas di dalam Tugas Akhir ini memiliki beberapa batasan. Batasan tersebut di antaranya sebagai berikut: 1. Dokumen rancangan berisi diagram kasus penggunaan dengan

4

2. 3. 4. 5. 6.

deskripsinya dan diagram urutan dari satu sistem, misal sistem ATM. Deskripsi kasus penggunaan berisi kalimat alur kejadian dasar (basic flow) dari kasus penggunaan. Dokumen rancangan dibuat dengan menggunakan aplikasi pemodelan StarUML 2 [2]. Dokumen rancangan dalam format “.xmi”. Berkas tersebut dihasilkan melalui penggunaan XMI extension StarUML 2 [3]. Bahasa yang digunakan pada dokumen rancangan adalah bahasa Inggris. Kakas bantu yang dibuat merupakan aplikasi berbasis desktop.

1.4

Tujuan

Tujuan dari pengerjaan Tugas Akhir ini adalah membuat kakas bantu yang dapat mendeteksi ketidaksesuaian antara diagram urutan (sequence diagram) dan diagram kasus penggunaan (use case diagram).

1.5

Manfaat

Adapun manfaat dari hasil pengerjaan Tugas Akhir ini. Manfaat tersebut antara lain: 1. Membantu analis sistem untuk menghasilkan rancangan diagram urutan yang sesuai dengan alur yang ada deskripsi kasus penggunaan. 2. Mempercepat waktu pengembangan perangkat lunak dari sebuah proyek perangkat lunak.

1.6

Metodologi

Tahapan-tahapan untuk mengerjakan Tugas Akhir ini dijabarkan sebagai berikut:

5 1. Penyusunan proposal Tugas Akhir Proposal Tugas Akhir berisi gagasan dari Tugas Akhir yang akan dikerjakan. Proposal Tugas Akhir berisi pendahuluan yang terdiri dari latar belakang diajukannya usulan Tugas Akhir, rumusan masalah yang diangkat, batasan masalah, tujuan, dan manfaat dari pembuatan tugas akhir. Selain itu, tinjauan pustaka yang digunakan juga dijabarkan sebagai referensi pendukung pengerjaan Tugas Akhir. Subbab metodologi berisi penjelasan mengenai tahapan penyusunan Tugas Akhir mulai dari penyusunan proposal hingga penyusunan buku Tugas Akhir. Terdapat pula subbab jadwal kegiatan yang menjelaskan jadwal pengerjaan Tugas Akhir. 2. Studi literatur Studi literatur yang dipelajari untuk mendukung pengerjaan Tugas Akhir, antara lain diagram kasus penggunaan (use case diagram), deskripsi kasus penggunaan (use case description), diagram urutan (sequence diagram), konsep ketidaksesuaian diagram urutan dan diagram kasus penggunaan, XML Metadata Interchange (XMI), StarUML, dan pemrosesan bahasa alami (natural language processing). Selain itu, metode perhitungan kemiripan semantik kalimat, perhitungan kemiripan kata, dan basis data leksikal bahasa Inggris, WordNet, juga menjadi bahan studi literatur. 3. Analisis dan perancangan sistem Analsis dan perancangan sistem yang digunakan berdasarkan pengembangan perangkat lunak berbasis objek. Analisis dan perancangan sistem diawali dengan analisis dan pendefinisian kebutuhan sistem terhadap masalah yang sedang dihadapi. Selain itu, analisis aktor dan kandidat-kandidat kelas (class) yang berinteraksi di dalam sistem. Tahap perancangan dibagi menjadi beberapa tahap. Tahap tersebut antara lain: (a) Perancangan diagram UML, (b) Perancangan antarmuka perangkat lunak, dan

6 (c) Perancangan proses perancangan lunak. 4. Implementasi sistem Tahap ini dilakukan implementasi perangkat lunak. Implementasi perangkat lunak didasarkan pada perancangan sistem yang telah dilakukan sebelumnya. Perangkat lunak diimplementasikan dengan bahasa pemrograman Java. Adapun tahap implementasi perangkat lunak. Tahap tersebut antara lain: (a) Implementasi antarmuka perangkat lunak, (b) Implementasi ekstraksi deskripsi kasus penggunaan dan diagram urutan dari sebuah dokumen rancangan, (c) Implementasi pemecahan kalimat (sentence breaking), penentuan kelas kata (part-of-speech tagging), dan pembentukan kata dasar (lemmatization) pada suatu kalimat, (d) Implementasi perhitungan kemiripan semantik antar kalimat. (e) Implementasi ekspor hasil deteksi ketidaksesuaian ke dalam laporan dengan format “.doc”, “.docx”, atau “.pdf”. 5. Pengujian dan evaluasi Pengujian dan evaluasi perangkat lunak yang telah dibuat dibagi ke dalam empat tahap, yaitu: (a) Pengujian data pelatihan (training data) dengan pendekatan perhitungan kemiripan semantik kalimat yang telah dipilih. Hasil pengujian ini digunakan sebagai dasar menentukan ambang batas (threshold) terbaik untuk mendeteksi ketidaksesuaian antara diagram kasus penggunaan dan diagram urutan. (b) Pengujian data uji (testing data) dengan menerapkan ambang batas terbaik yang telah didapatkan sebelumnya. Hasil pengujian ini digunakan untuk membandingkan hasil pemeriksaan ketidaksesuaian oleh perangkat lunak dengan ahli rekayasa perangkat lunak. (c) Pengujian fungsional perangkat lunak dengan menggunakan black-box testing. Pengujian dengan metode ini bertu-

7 juan untuk mengetahui apakah perangkat lunak yang dibangun sudah sesuai dengan hasil yang diharapkan. (d) Pengujian non-fungsional perangkat lunak untuk aspek usability. Pengujian ini digunakan untuk mengetahui seberapa besar kemudahan perangkat lunak dipelajari dan digunakan oleh pengguna. Data dokumen rancangan diambil dari sistem yang sudah ada rancangannya, seperti sistem ATM dan ARENA. Sumber dokumen rancangan berasal dari buku dengan topik rekayasa perangkat lunak dan internet. 6. Penyusunan buku Tugas Akhir Tahap ini dilakukan penyusunan laporan yang menjelaskan dasar teori, metode yang digunakan dalam Tugas Akhir, dan hasil dari implementasi perangkat lunak yang telah dibuat. Sistematika penulisan buku Tugas Akhir secara garis besar, terdiri dari pendahuluan, tinjauan pustaka, analisis dan perancangan sistem, implementasi sistem, pengujian dan evaluasi, dan kesimpulan dan saran.

1.7 Sistematika Penulisan Laporan Tugas Akhir Buku Tugas Akhir bertujuan untuk memberikan gambaran dari pengerjaan Tugas Akhir. Secara garis besar, buku Tugas Akhir ini terdiri dari bagian berikut ini: 1. Bab I Pendahuluan Bab ini berisi latar belakang, tujuan, dan manfaat dari pengerjaan Tugas Akhir. Selain itu, rumusan masalah, batasan masalah, metodologi, dan sistematika penulisan Tugas Akhir juga merupakan bagian dari bab ini. 2. Bab II Tinjauan Pustaka Bab ini berisi penjelasan dasar teori dan penunjang yang digunakan untuk mendukung pengerjaan Tugas Akhir. Dasar teori yang digunakan, antara lain diagram kasus penggunaan (use case di-

8 agram), deskripsi kasus penggunaan (use case description), diagram urutan (sequence diagram), konsep ketidaksesuaian diagram urutan dan diagram kasus penggunaan, XML Metadata Interchange (XMI), StarUML, pemrosesan bahasa alami (natural language processing), metode perhitungan kemiripan semantik kalimat, metode perhitungan kemiripan kata, dan WordNet. 3. Bab III Analisis dan Perancangan Sistem Bab ini berisi analisis dan perancangan perangkat lunak yang dibuat. Analisis perangkat lunak mendefinisikan kebutuhan sistem terhadap masalah yang dihadapi yang meliputi analisis aktor yang terlibat di dalam sistem, spesifikasi kebutuhan perangkat lunak, dan analisis kandidat kelas (class analysis). Perancangan perangkat lunak meliputi perancangan diagram UML (di antaranya, use case diagram, activity diagram, sequence diagram, class diagram, dan package diagram), perancangan antarmuka, dan perancangan proses yang terjadi di dalam perangkat lunak. 4. Bab IV Implementasi Perangkat Lunak Bab ini membahas implementasi dari hasil perancangan perangkat lunak yang telah dilakukan sebelumnya. Penjelasan berupa deskripsi dengan potongan kode sumber dari proses yang terjadi di dalam perangkat lunak. Proses tersebut antara lain, proses mengekstraksi deskripsi kasus penggunaan dan diagram urutan dari dokumen rancangan, proses mendeteksi ketidaksesuaian, proses menghitung kemiripan kalimat antara kalimat alur kejadian kasus penggunaan dengan triplet, proses menghitung kemiripan kata, dan proses mengekspor hasil deteksi ketidaksesuaian ke bentuk laporan. Selain itu, implementasi dari antarmuka perangkat lunak juga dibahas dalam bab ini. 5. Bab V Pengujian dan Evaluasi Bab ini membahas pengujian hasil deteksi ketidaksesuaian dengan membandingkan hasil dari perangkat lunak dan dari ahli melalui dokumen rancangan yang diujikan. Penjelasan pengujian data pelatihan juga dijelaskan di dalam bab ini. Evaluasi

9 pengujian hasil deteksi ketidaksesuaian ditentukan melalui seberapa besar kesepakatan antara perangkat lunak dengan ahli. Kesepakatan tersebut dapat ditentukan melalui nilai kappa statistic [35]. Selain itu, terdapat pengujian fungsional perangkat lunak melalui black-box testing dan non-fungsional perangkat lunak pada aspek usability. Hasil pengujian fungsional ditentukan dengan melihat apakah hasil yang diharapkan telah sesuai dengan hasil yang didapatkan. Untuk pengujian non-fungsional, hasil diperoleh dari kuesioner yang telah diisi oleh partisipan. 6. Bab VI Kesimpulan dan Saran Bab ini berisi kesimpulan dari hasil pengujian yang telah dilakukan dan saran untuk pengembangan perangkat lunak ke depannya.

10 Halaman ini sengaja dikosongkan

BAB II TINJAUAN PUSTAKA

Bab ini berisi dasar teori, publikasi ilmiah, dan kakas bantu atau pustaka perangkat lunak yang digunakan untuk menunjang pembuatan perangkat lunak.

2.1 Diagram Kasus Penggunaan (Use Case Diagram) Diagram kasus penggunaan merupakan salah satu jenis diagram UML (unified modeling language). UML adalah sebuah bahasa standar yang membantu kebutuhan perangkat lunak untuk saling berkomunikasi [1]. Standar UML mengacu pada spesifikasi yang dikeluarkan oleh organisasi bernama Object Management Group (OMG). Saat ini, standar UML sudah mencapai versi UML 2 [4]. Banyak jenis kakas pemodelan diagram UML yang mengikuti standar UML 2. Salah satunya adalah aplikasi StarUML [2]. Diagram kasus penggunaan adalah gambaran grafis dari aktor, kasus penggunaan (use case), dan interaksinya yang menggambarkan sistem yang akan dibangun.

Gambar 2.1 Contoh diagram kasus penggunaan (use case diagram)1 1

Contoh diagram diambil dari https://www.andrew.cmu.edu/course/ 90-754/umlucdfaq.html (diakses terakhir 26 Juni 2016).

11

12 Tujuan dari pembuatan diagram kasus penggunaan adalah sebagai alat mendokumentasikan kebutuhan dasar aktor dan bagaimana kebutuhan tersebut akan dipenuhi. Selain itu, diagram ini juga berfungsi sebagai alat mengomunikasikan fungsionalitas sistem kepada stakeholder (pihak yang memiliki kepentingan terhadap sistem yang akan dibangun) karena kasus penggunaan menggunakan bahasa yang mudah dimengerti. Gambar 2.1 merupakan contoh dari diagram kasus penggunaan. Dari gambar tersebut, diagram kasus penggunaan disusun oleh dua komponen utama, yaitu aktor dan kasus penggunaan. Selain itu, terdapat komponen lain, seperti relasi dan batas sistem yang dijelaskan lebih lanjut pada Tabel 2.1. Tabel 2.1 Komponen diagram kasus penggunaan (use case diagram) Nama

Aktor (actor)

Kasus Penggunaan (use case)

Notasi

Keterangan Menggambarkan suatu peran yang dilakukan oleh objek yang berada di luar sistem yang berinteraksi langsung dengan sistem. “Photographer” menunjukkan nama dari aktor. Deskripsi sebuah perilaku sistem sebagai respon dari suatu aksi dari luar sistem (interaksi antara aktor dan sistem). “Take Picture” menunjukkan nama kasus penggunaan.

13 Tabel 2.1 Komponen diagram kasus penggunaan (use case diagram) (lanjutan) Nama

Asosiasi (association)

Include

Extend

Generalisasi (generalization)

Batas sistem (system boundary)

Notasi

Keterangan

Hubungan atau relasi dari aktor ke kasus penggunaan. Hubungan atau relasi yang mengindikasikan suatu kasus penggunaan utama (base use case) merujuk dan melibatkan perilaku sub-kasus penggunaan (sub-use case) lain. Hubungan atau relasi yang mengindikasikan suatu kasus penggunaan utama diperluas dengan perilaku sub-kasus penggunaan lain. Menggambarkan generalisasi dari sejumlah kasus penggunaan atau aktor yang lain. Menggambarkan batas antara aktor dan sistem. Terdapat kasus penggunaan apa saja yang ada di dalam sistem tersebut. “Camera” menunjukkan nama dari sistem.

14

2.2

Deskripsi Kasus Penggunaan (Use Case Description)

Setiap diagram kasus penggunaan (use case diagram) memiliki sebuah deskripsi yang menjelaskan interaksi antara aktor dan kasus penggunaan (use case). Deskripsi tersebut disebut dengan deskripsi kasus penggunaan. Interaksi aktor dan kasus penggunaan dideskripsikan melalui sebuah skenario dalam deskripsi kasus penggunaan. Setiap deskripsi kasus penggunaan harus mengandung informasi deskripsi singkat kasus penggunaan, skenario dalam bentuk alur kejadian (flow of events), yang terdiri dari alur dasar, alur alternatif, dan alur eksepsional. Selain itu, terdapat prakondisi dan pascakondisi dari kasus penggunaan. Rational Unified Process (RUP) menyediakan sebuah template untuk mendeskripsikan setiap kasus penggunaan. Template tersebut disusun sebagai berikut: Use Case Specification: <Use Case Name> 1. Use Case Name 1.1 Brief Description Mendeskripsikan tujuan dari kasus penggunaan dalam sebuah paragraf. 2. Flow of Events 2.1 Basic Flow Mendefinisikan kapan dan bagaimana kasus penggunaan mulai dan berakhir. Selain itu, aktor mana yang mengawali kasus penggunaan. Deskripsi ini berupa skenario dalam bentuk dialog antara aktor dan sistem (aktor melakukan apa dan respon apa yang diberikan oleh sistem). Dialog tersebut ditulis dalam sebuah urutan. 2.2 Alternative Flow 2.2.1 Mendefinisikan alur alternatif karena sebab tertentu pada skenario utama (basic flow). Bentuk alur alternatif juga berupa dialog antara aktor dan sistem yang ditulis dalam sebuah urutan. Jika alur alternatif selesai, maka alur kembali ke skenario utama.

15 2.2.2 <Second Alternative Flow> Alur alternatif kedua dan selanjutnya. 2.3 Exceptional Flow Mendefinisikan setiap kejadian yang menyebabkan tujuan aktor dalam kasus penggunaan tidak dapat tercapai. Alur ini juga berbentuk dialog aktor dan sistem yang ditulis dalam sebuah urutan. 3. Special Requirements 3.1 < First Special Requirement > Mendefinisikan pemenuhan atau kondisi khusus agar kasus penggunaan dapat dijalankan. Contohnya, aturan bisnis, atribut kualitas, dan pemenuhan lainnya. 3.2 < Second Special Requirement > Kebutuhan khusus kedua dan selanjutnya. 4. Preconditions Mendefinisikan kondisi awal yang harus dipenuhi sebelum kasus penggunaan dimulai. 4.1 < Precondition One > Kondisi awal pertama dan selanjutnya. 5. Postconditions Mendefinisikan kondisi akhir yang dicapai setelah kasus penggunaan selesai. 5.1 < Postcondition One > Kondisi akhir pertama dan selanjutnya. 6. Extension Points 6.1 < Name of Extension Point> Mendefinisikan titik lokasi ekstensi dalam bentuk alur kejadian. Titik ekstensi merupakan perluasan dari kasus penggunaan utama (base use case). Tidak semua bagian dari template di atas harus ada pada setiap kasus penggunaan. Bagian yang harus selalu ada adalah nama kasus penggunaan dan deskripsi singkatnya, alur dasar, dan pascakondisi karena tidak semua kasus penggunaan memiliki alur alternatif dan alur eksepsional, kebutuhan khusus, prakondisi, dan titik ekstensi

16 [1]. Bagian flow of events pada deskripsi kasus penggunaan menjadi panduan analis sistem untuk menurunkan kelas-kelas (class) pada tahap analisis perangkat lunak. Kelas tersebut nantinya saling berinteraksi pada diagram urutan (sequence diagram).

2.3

Diagram Urutan (Sequence Diagram)

Diagram urutan adalah gambaran grafis yang menggambarkan perilaku objek yang ada pada kasus penggunaan (use case) dengan mendeskripsikan pesan (message) yang dimiliki kelas (class). Diagram ini juga merupakan salah satu jenis diagram UML, di samping diagram kasus penggunaan (use case diagram) yang telah dibahas sebelumnya.

Gambar 2.2 Contoh diagram urutan (sequence diagram)2 2

Contoh diagram diambil dari http://www1.unipa.it/manfredi. bruccoleri/bpm/Week_6_files/Es%204%20Solution.pdf (diakses terakhir 26 Juni 2016).

17 Realisasi kasus penggunaan dalam bentuk skenario pada deskripsi kasus penggunaan (use case description) secara detail digambarkan pada diagram ini. Diagram urutan mengekspresikan skenario berdasarkan urutan waktu, apa yang terjadi pertama kali, berikutnya, dan seterusnya. Hal tersebut digunakan untuk mendefinisikan urutan pesan (message ordering). Tujuan dari pembuatan diagram urutan adalah sebagai alat pelacak kesesuaian logika interaksi antara objek-objek di dalam sistem sesuai urutan waktu interaksi tersebut terjadi. Kesesuaian interaksi antara skenario pada deskripsi kasus penggunaan bisa dilihat dengan menggunakan diagram ini. Pada dasarnya, diagram urutan menunjukkan perilaku kasus penggunaan yang hendak diimplementasikan ke dalam perangkat lunak. Gambaran umum diagram urutan digambarkan pada Gambar 2.2. Dari gambar tersebut, diagram terdiri dari komponen seperti, aktor, objek dari suatu kelas, dan pesan. Selain itu, terdapat komponen lain yang menyusun diagram urutan. Penjelasan masing-masing komponen tersebut dijelaskan secara detail pada Tabel 2.2. Tabel 2.2 Komponen diagram urutan (sequence diagram) Nama

Aktor (actor)

Notasi

Keterangan Menggambarkan suatu peran yang dilakukan oleh objek di luar sistem (entitas eksternal) yang berinteraksi langsung dengan sistem. “Passenger” merupakan nama dari aktor.

18 Tabel 2.2 Komponen diagram urutan (sequence diagram) (lanjutan) Nama

Notasi

Keterangan

Objek (object)

Menggambarkan sebuah objek dalam suatu sistem. Objek merupakan instance dari sebuah kelas (class). Bagian “InternalButton” menunjukkan nama dari kelas. Bagian di depan tanda “:” menunjukkan nama objek.

Lifeline

Menggambarkan daur hidup dari sebuah objek.

Activation bar

Message

Menggambarkan durasi pengerjaan sebuah pesan (message). Menggambarkan pesan sebagai bentuk komunikasi antar objek. Pesan berupa sebuah method. Terdapat nama method dan parameter pada pesan. “selectFloorNumber” merupakan nama dari sebuah method.


Reply Message

Asynchronous Message

Create Message

Delete Message

Notasi

Keterangan Menggambarkan umpan balik (feedback) sebuah operasi pada pesan. “amountDue” merupakan nama hasil kembalian sebuah operasi pada pesan. Menggambarkan jenis pesan di mana pesan ini mengaktifkan sebuah operasi yang berjalan bersamaan dengan sebuah operasi lain dari suatu pesan. Menggambarkan jenis pesan untuk membuat sebuah objek baru yang dikirim oleh objek yang lain. Menggambarkan jenis pesan untuk menghancurkan sebuah objek yang dikirim oleh objek lain.


Interaction

2.4

Notasi

Keterangan Menggambarkan sebuah dasar dari diagram urutan untuk meletakkan komponennya secara konsisten. Terdapat nama kasus penggunaan pada pojok kiri atas.

Ketidaksesuaian Diagram Urutan dan Diagram Kasus Penggunaan

Konsistensi antara rancangan diagram UML sangat penting. Hal ini disebabkan karena rancangan diagram yang baik merupakan kunci ketepatan (correctness) implementasi kebutuhan pengguna. Contoh, diagram UML yang membutuhkan pengecekan konsistensi adalah hubungan diagram urutan dengan diagram kasus penggunaan [5]. Skenario berupa interaksi aktor dan sistem pada dalam bentuk alur kejadian pada kasus penggunaan (use case) menjadi urutan pesan (message) yang dikirimkan oleh objek aktor ke boundary atau sistem ke boundary. Hal tersebut menjadi dasar pengecekan ketidaksesuaian. Skenario kasus penggunaan dibuat saat tahap elisitasi kebutuhan, sedangkan diagram urutan dibuat saat tahap analisis. Tahap analisis fokus untuk menghasilkan model sistem yang benar, lengkap, konsisten, dan bisa diverifikasi [6]. Model yang dihasilkan ada tiga jenis, yaitu functional model, object model, dan dynamic model. Functional model direpresentasikan oleh kasus penggunaan dan skenarionya, object model direpresentasikan oleh diagram kelas (class diagram), dan dynamic model direpresentasikan oleh

21 diagram urutan. Saat menganalisis object model, analis sistem menentukan tiga jenis kandidat objek (boundary, control, dan entity) dari skenario kasus penggunaan. Pendekatan yang digunakan untuk menentukan kandidat kelas adalah menelusuri kata benda pada skenario kasus penggunaan. Contoh, kata catalog pada alur skenario customer browses through catalog menjadi kelas BrowseInterface dengan jenis objek boundary. Kata kerja pada alur skenario memjadi kandidat pesan atau operasi kelas. Mengambil contoh sebelumnya, kata kerja browses menjadi operasi browseItem. Tahap analisis object model dilanjutkan dengan analisis dynamic model. Tahap ini dilakukan pemetaan kasus penggunaan menjadi diagram urutan. Diagram urutan bergantung pada kasus penggunaan dengan objek-objeknya. Hasil dari analisis object model berupa objek-objek dengan operasinya saling berinteraksi pada diagram urutan. Bagian yang paling penting pada diagram urutan adalah urutan operasi yang dikirimkan dari objek satu ke objek lainnya. Hal ini disebabkan diagram urutan merealisasikan perilaku objekobjek yang ada pada skenario kasus penggunaan.

2.5 XML Metadata Interchange (XMI) XML Metadata Interchange (XMI) [7] adalah sebuah standar pertukaran informasi metadata melalui Extensible Markup Language (XML). Standar tersebut berdasarkan Meta Object Facility (MOF), sebuah standar meta-meta-model dari Object Management Group (OMG) [8]. XMI menggabungkan sebuah meta-meta-model ke sebuah teks dalam format XML. Untuk menghasilkan informasi metadata ke sebuah teks dalam format XML, XMI mendefinisikan serangkaian aturan meta-model berdasarkan MOF meta-metamodel. Salah satu contoh meta-model adalah UML (unified modeling language). Sebuah UML didefinisikan sebagai sebuah model yang terdiri dari informasi metadata yang saling berkaitan karena mendeskrip-

22 sikan informasi yang saling berhubungan, mendefinisikan sebuah rangkaian aturan yang mendefinisikan struktur dan konsistensi, dan memiliki makna dalam sebuah kerangka semantik umum [9]. Kelebihan dari XMI adalah portability, memungkinkan sebuah model bisa digunakan di berbagai jenis kakas rekayasa perangkat lunak. Hal tersebut bisa dilakukan karena XMI mengandung informasi metadata yang bisa direpresentasikan ke dalam sebuah diagram UML atau sebaliknya dari diagram UML ke XMI (reverse engineering). Ada berbagai jenis aplikasi pemodelan UML yang mendukung konversi dari diagram UML ke dalam XMI atau sebaliknya dari XMI ke diagram UML. StarUML merupakan salah satu aplikasi yang menyediakan fitur tersebut. Fitur ini bisa dijalankan dengan menambahkan XMI extension [3] pada aplikasi StarUML 2 [2]. Dengan menggunakan bantuan extension tersebut, elemen yang ada pada XMI bisa menunjukkan apa dan bagaimana komponen yang ada pada rancangan diagram UML disusun. Setiap elemen terdiri dari atribut dan nilai atribut. Penjelasan masing-masing elemen dan atribut penyusunnya dijelaskan pada Tabel 2.3. Diagram kasus penggunaan (use case diagram), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram) dipilih sebagai contoh penjelasan. Tabel 2.3 Elemen penting XMI pada diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram) Elemen

Atribut version

Keterangan Mendefinisikan versi XML pada setiap deklarasi dokumen XML.

encoding

Mendefinisikan karakter unicode yang digunakan. Biasanya, UTF-8 yang paling sering digunakan.

23 Tabel 2.3 Elemen penting XMI pada diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram) (lanjutan) Elemen

xmi:XMI

Atribut xmi:version

Mendefinisikan versi XMI.

xmlns:uml

Mendefinisikasi standar spesifikasi UML pada setiap deklarasi XMI.

xmlns:xmi

Mendefinisikan standar spesifikasi XMI pada setiap deklarasi XMI.

exporter xmi:Documentation

Mendefinisikan nama ektensi (extension) yang mengekspor berkas UML ke dalam XMI.

exporterVersion

Mendefinisikan versi kakas yang melakukan konversi diagram UML ke XMI.

xmi:id

Menunjukkan nilai unik setiap komponen rancangan. Nilai berupa universally unique identifier (UUID).

name

Mendefinisikan nama model UML dalam satu rancangan.

xmi:type

Mendefinisikan tipe model UML dalam satu rancangan.

xmi:id

Menunjukkan nilai unik setiap komponen rancangan. Nilai berupa UUID.

uml:Model

packagedElement

Keterangan


Atribut

name

Menunjukkan nama komponen. Komponen bisa berupa aktor, kasus penggunaan (use case), lifeline, dan sebagainya.

xmi:type

Mendefinisikan tipe komponen yang menyusun diagram UML. Tipe komponen bisa berupa aktor, kasus penggunaan, lifeline, dan sebagainya.

xmi:id


xmi:type

Mendefinisikan deklarasi anggota atau komponen lain yang terlibat. Bisa digunakan untuk hubungan asosiasi suatu kasus penggunaan atau menemukan judul frame diagram urutan.

xmi:id


ownedMember

ownedEnd

Keterangan

type

Menunjukkan referensi UUID komponen yang terlibat.


Atribut

xmi:type

memberEnd

documentation

lifeline

xmi:idref

Keterangan Mendefinisikan anggota atau komponen mana saja yang terlibat dalam hubungan asosiasi suatu kasus penggunaan. Mendefinisikan referensi UUID dari ownedEnd.

value

Mendefinisikan dokumentasi diagram UML. Misal, deskripsi kasus penggunaan. Nilai terdapat pada atribut value.

xmi:id


name

Menunjukkan nama dari lifeline.

xmi:type

Menunjukkan komponen lifeline. Nilai atribut ini adalah uml:Lifeline.

represents

Mendefinisikan komponen lifeline. Nilai name menunjukkan nama objek dan represents referensi UUID dari kelas (class) yang bersangkutan.


Atribut

Keterangan

xmi:id


name

Menunjukkan nama message.

message

fragment

xmi:type

Menunjukkan komponen message. Nilai atribut ini adalah uml:Message.

messageSort

Menunjukkan jenis message. Jenis message bisa berupa synchronous, asynchronous, atau reply message.

receiveEvent

Menunjukkan referensi UUID dari lifeline yang menerima message tersebut.

sendEvent

Menunjukkan referensi UUID dari lifeline yang mengirim message tersebut.

xmi:id


covered

Nilai covered menunjukkan referensi UUID dari lifeline.

xmi:type

Mendefinisikan komponen fragment yang bernilai uml:OccurrenceSpecification.

27

2.6 StarUML StarUML [2] adalah sebuah aplikasi pemodelan UML (unified modeling language) yang dikembangkan oleh MKLab. StarUML dikembangkan untuk memberikan alternatif aplikasi pemodelan UML komersial yang sudah ada, seperti Rational Rose dan Together. Secara umum, fitur yang didukung oleh StarUML, antara lain pemodelan diagram UML yang sesuai dengan standar UML 2, pengecekan model UML sesuai aturan, dan penambahan fungsional melalui extension. Aplikasi ini terdiri dari dua versi, yaitu StarUML v1 dan StarUML 2. StarUML v1 [10] merupakan versi open source dan sudah tidak di-maintain lagi. Oleh sebab itu, StarUML v1 dilanjutkan dengan rilisnya StarUML 2. Kedua versi StarUML tersebut mendukung sebelas jenis diagram UML. Salah satunya adalah diagram kasus kegunaan (use case diagram) dan urutan (sequence diagram).

Gambar 2.3 Contoh deskripsi kasus penggunaan (use case description) pada aplikasi StarUML 2 Dengan menggunakan aplikasi StarUML, aplikasi tidak hanya mendukung ekspor dan impor XMI dari diagram UML akan tetapi dokumentasi komponen-komponen yang ada pada diagram UML. Dokumentasi berupa plain text yang berisi penjelasan suatu komponen diagram UML. Contoh dokumentasi diagram kasus penggunaan dari kasus penggunaan (use

28 case) “Take Picture” dalam bentuk deskripsi kasus penggunaan (use case description) ditunjukkan oleh Gambar 2.3. Ada dua bagian penting pada gambar tersebut, yaitu kasus penggunaan “Take Picture” yang sedang dipilih (tengah) dan dokumentasi dari kasus penggunaan tersebut (pojok kanan bawah). Dokumentasi menunjukkan teks yang berisi deskripsi dari kasus penggunaan “Take Picture”, seperti deskripsi singkat (brief description) dan alur kejadian dasar (basic flow) dari kasus penggunaan tersebut. Hasil dokumentasi ini secara otomatis akan masuk ke dalam berkas XMI apabila diagram UML yang bersangkutan diekspor ke dalam XMI. Hasil XMI ini memungkinkan untuk digunakan pada jenis aplikasi pemodelan UML yang berbeda. Namun, hasil XMI dari StarUML 2 tidak bisa digunakan di StarUML v1 dan sebaliknya karena perbedaan versi XMI.

2.7

Pemrosesan Bahasa Alami (Natural Language Processing)

Pemrosesan bahasa alami atau yang dikenal dengan NLP adalah cabang ilmu komputer yang mengkaji interaksi antara komputer dengan bahasa (alami) manusia. Adapun ranah penelitian yang sering dijadikan objek penelitian NLP. Ranah penelitian tersebut, antara lain automatic summarization, machine translation, morphological segmentation, name entity recognition (NER), part-of-speech tagging, parsing, question answering, sentence breaking, sentiment analysis, dan word sense disambiguation. Dalam pengerjaan Tugas Akhir ini, pemrosesan bahasa alami yang digunakan adalah sebagai berikut: (a) Sentence breaking Sentence breaking adalah proses memecah sebuah teks utuh ke dalam kalimat-kalimat yang menyusunnya. Sebuah kalimat sering diakhiri dengan tanda baca titik (.) atau lainnya, seperti tanda tanya (?). Namun, tidak semua kalimat bisa ditandai melalui tanda baca tersebut. Contoh, teks “Since 2011, Gov. Bill Haslam and the General Assembly have partnered to increase education funding by more than $730 million, including more than $340 million for teacher salaries. Education has become a priority in Tennessee, and we have demonstrated that commitment through increased funding where it really counts.” disusun oleh dua kalimat. Apabila menggunakan tanda baca titik mi-

29 salnya untuk menandai sebuah kalimat, teks tersebut terdiri dari tiga kalimat. “Since 2011, Gov.” menjadi kalimat sendiri, padahal itu bukan merupakan sebuah kalimat. Hal ini terjadi karena hanya memerhatikan tanda baca titik tanpa memerhatikan singkatan, seperti singkatan “Gov.” pada kalimat tersebut. Sentence breaking ini juga dikenal dengan sebutan sentence boundary disambiguation. (b) Part-of-speech tagging Part-of-speech tagging atau yang dikenal dengan POS tagging adalah penentuan kelas kata dalam sebuah kalimat dengan memberikan suatu label pada kata. Label menunjukkan kelas kata tersebut apakah suatu kata merupakan kata benda, kata kerja, kata sifat, atau kelas kata lainnya. Contoh, kata “book” pada kalimat “the book is on the table.” merupakan kata benda. Namun, kata “book” pada kalimat “they book a flight.” merupakan kata kerja. Penentuan kelas kata ini harus memerhatikan gramatikal dan morfologi dari sebuah kalimat. Misalnya, bahasa Inggris dan bahasa Jepang memiliki struktur kalimat yang berbeda. Kalimat dalam bahasa Inggris memiliki penanda POS yang dimodelkan dalam Penn Treebank [11] bahasa Inggris. Model ini dijelaskan secara detail pada Tabel 2.4.

Tabel 2.4 Model Penn Treebank bahasa Inggris No.

Penanda

Definisi

Keterangan

1

CC

Coordinating conjunction

2

CD

Cardinal number

3

DT

Determiner

4

EX

Existential

Konjungsi yang diletakkan di antara kata, frasa, klausa, atau kalimat yang setara. Contoh, and, but, nor, or, dan yet. Angka yang menunjukkan seberapa banyak dari sesuatu. Contoh, one, two, dan three. Penanda ini terdiri dari article dan indefinite determiner. Contoh, a, an, every, no, dan the. Penanda ini menunjukkan proposisi keberadaan sesuatu. Contoh, there dalam kalimat there is something in the water.

30 Tabel 2.4 Model Penn Treebank bahasa Inggris (lanjutan) No.

Penanda

Definisi

Keterangan

5

FW

Foreign word

6

IN

Preposition atau Subordinating conjunction

7

JJ

Adjective

8

JJR

Adjective parative)

9

JJS

Adjective (superlative)

10

LS

List item maker

11

MD

Modal verb

12

NN

Noun (singular atau mass)

13

NNS

Noun (plural)

Penanda ini menunjukkan kata asing, seperti persona non grata. Penanda ini menunjukkan kata depan in yang mendahului frasa kata benda. Selain itu, kata at dan on. Kata sifat, seperti kata hardworking dalam frasa a hardworking student. Kata sifat perbandingan yang diakhiri dengan -er. Contoh, kata higher, more, dan less. Kata sifat perbandingan yang diakhiri dengan -est. Contoh, highest, most, dan least. Penanda ini mencakup huruf dan angka ketika digunakan untuk menandai butir atau hal dalam sebuah daftar. Penanda ini terdiri dari semua kata kerja yang tidak berakhiran s pada third person singular person. Contoh, can, could, may, dan must. Kata benda tunggal atau kata benda yang tidak bisa dihitung. Contoh, book, pencil, water, dan progress. Kata benda jamak. Contoh, books dan pencils.

(com-


Penanda

Definisi

Keterangan

14

NNP

Proper noun (singular)

15

NNPS

Proper noun (plural)

16

PDT

Predeterminer

17

POS

Possessive ding

18

PRP

Personal pronoun

19

PRP$

Possessive noun

Nama dari seseorang, tempat, atau benda tunggal yang perlu ditulis dengan huruf kapital. Contoh, John Smith, Institut Teknologi Sepuluh Nopember, dan Indonesia. Nama dari seseorang, tempat, atau benda jamak yang perlu ditulis dengan huruf kapital. Contoh, the United States. Penanda ini terdiri dari determiner yang mendahului sebuah article atau possessive pronoun. Contoh, kata all pada all his marbles dan such pada such a good time. Kepemilikan kata benda yang diakhiri dengan ’s atau ’. Contoh, John’s idea dan the parents’ distress. Kata ganti yang berkaitan dengan orang dalam struktur grammar. Contoh, orang pertama (I), orang kedua (you), dan orang ketiga (she, he, it). Kata ganti milik, seperti my, your, his, her, its, our, dan their.

en-

pro-


Penanda

Definisi

Keterangan

20

RB

Adverb

21

RBR

Adverb (comparative)

22

RBS

Adverb (superlative)

23

RP

Particle

24

SYM

Symbol

Kata keterangan yang memodifikasi sebuah kata kerja, kata sifat, kata keterangan lainnya, frasa kata benda, klausa, atau kalimat. Contoh, kebanyakan kata yang diakhiri dengan -ly, kata quite, too, very, dan penanda negatif seperti not, n’t, dan never. Kata keterangan yang diakhiri dengan perbandingan -er atau diawali dengan more (termasuk bentuk perbandingan irregular), seperti kata harder dalam kalimat Jim works harder than his brother. Kata keterangan yang diakhiri dengan perbandingan -est atau diawali dengan most. Termasuk bentuk perbandingan irregular. Kata yang tidak dapat berubah bentuknya dan tidak masuk ke dalam part-of-speech utama (kata benda, kata kerja, kata sifat, kata keterangan). Contoh, kata to pada to fly. Kata tersebut juga bisa menjadi kata depan pada kalimat I’m going to English next month. Penanda ini digunakan untuk simbol matematika, ilmiah, dan ekspresi lain yang bukan merupakan kata dalam bahasa Inggris. Contoh, nama zat kimia dan unit pengukuran.


Penanda

Definisi

Keterangan

25

TO

to

26

UH

Interjection

27

VB

Verb (base form)

28

VBD

Verb (past tense)

29

VBG

30

VBN

Verb (gerund atau present participle) Verb (past participle)

31

VBP

Penanda untuk menandai to, baik sebagai kata depan maupun infinitive marker. Penanda ini mencakup kata my dalam kalimat My, what a beautiful day, oh, please, well, dan yes. Penanda ini digolongkan menjadi imperative, infinitives, dan subjunctives. Contoh, imperative pada Do it!, infinitives pada You should do it, dan subjunctives pada We suggested that he do it. Kata kerja bentuk lampau, termasuk conditional form menggunakan to be. Contoh, kalimat I saw him yesterday dan If I were you, ... Kata kerja bentuk gerund atau sedang berlangsung. Contoh, kalimat I am taking a note. Kata kerja yang biasanya diakhiri dengan -ed yang digunakan untuk perfect tense dan passive voice. Contoh, kalimat She has finished the report. Kata kerja untuk selain orang ketiga tunggal. Contoh, kalimat You read a book.

32

VBZ

Verb (present tense-other than 3rd person singular) Verb (present tense-3rd person singular)

Kata kerja untuk orang ketiga tunggal. Contoh, kalimat He sings a song.


Penanda

Definisi

Keterangan

33

WDT

Wh-determiner

Penanda ini mencakup kata which. Penanda ini mencakup kata what, who, dan whom. Penanda ini mencakup kata whose. Penanda ini mencakup kata how, where, dan why.

34

WP

Wh-pronoun

35

WP$

36

WRB

Wh-pronounpossessive Wh-adverb

(c) Lemmatization Lemmatization adalah proses menghilangkan variasi dari sebuah kata (imbuhan) untuk mendapatkan bentuk dasar dari kata tersebut. Bentuk dasar yang didapatkan disebut sebagai lemma. Contoh, kata “better” memiliki “good” sebagai lemma dan kata “walk” merupakan bentuk dasar dari kata “walking”. Lemmatization berbeda dengan stemming yang biasanya hanya menghilangkan akhiran dari sebuah kata. Lemmatization mendapatkan bentuk dasar suatu kata dengan memerhatikan konteks kata tersebut pada suatu kalimat. Misal, hasil POS tagging atau pengecekan kata pada suatu dictionary. Pemrosesan bahasa alami di atas dapat dibantu oleh pustaka Stanford CoreNLP. Stanford CoreNLP adalah pustaka yang menyediakan analisis bahasa alami, seperti name entity recognition, part-of-speech tagging, dan lemmatization [12]. Standford CoreNLP mendukung bahasa Inggris sebagai bahasa utama. Selain itu, bahasa lain, seperti bahasa Arab dan bahasa Jerman juga didukung oleh pustaka ini.

2.8

Perhitungan Kemiripan Kalimat

Ilmu bahasa menggunakan hubungan semantik antar kata untuk menentukan kemiripan antar kalimat. Ada banyak pendekatan untuk menghitung kemiripan semantik antar kata. Pendekatan ini dijelaskan lebih detail pada subbab perhitungan kemiripan kata. Subbab ini membahas beberapa pendekatan perhitungan kemiripan kalimat. Pendekatan tersebut di antaranya sebagai berikut:

35

2.8.1 Kemiripan Semantik Kalimat (Sentence Semantic Similarity) Semantik didefinisikan sebagai ilmu tentang makna kata dan kalimat. Dua kalimat yang disusun oleh kata dan struktur yang berbeda bisa memiliki makna yang sama atau mirip. Contoh, kalimat “He is a bachelor.” dengan “He is an unmarried man.”. Kedua kalimat tersebut memiliki makna yang sama, walaupun disusun oleh kata yang berbeda. Perhitungan kemiripan semantik kalimat memiliki banyak pendekatan. Pertama, Li et al. [13] mengajukan sebuah vektor semantik (semantic vector) sebagai perhitungan kemiripan kalimat. Misal, terdapat kalimat s1 dan s2 . Ada sebuah kalimat baru yang dibentuk oleh gabungan kata (tanpa duplikasi) dari kalimat s1 dan s2 . Kemiripan kalimat dihitung dengan menemukan nilai kemiripan maksimum antara kata di kalimat s1 dengan kalimat baru. Hal yang sama juga dilakukan untuk kalimat s2 . Perhitungan tersebut menghasilkan vektor semantik yang berisi nilai maksimum pasangan kata dari kedua kalimat. Sehingga, kemiripan semantik antara dua kalimat (simssv ) didefinisikan sebagai cosine similarity vektor semantik dari kedua kalimat. Perhitungan ditunjukkan oleh Persamaan 2.1: s1 · s2 simssv (s1 ,s2 ) = (2.1) ∥s1 ∥∥s2 ∥ Kedua, Lee [14] mengajukan metode kemiripan semantik kalimat berdasarkan vektor semantik. Metode ini sama dengan metode yang dipaparkan oleh Li et al., tetapi terdapat perbedaan. Perbedaan tersebut terletak pada penggabungan kata dari kedua kalimat. Metode ini hanya menggabungkan kata benda dan kata kerja dari kedua kalimat. Misal, terdapat kalimat A dan kalimat B. Membentuk himpunan gabungan kata benda kalimat A dan kata benda kalimat B dan himpunan gabungan kata kerja kalimat A dan kata kerja kalimat B. Kemudian, mendapatkan vektor semantik kata benda dan vektor semantik kata kerja dari kedua kalimat dengan cara menghitung kemiripan maksimum antar kata. Sebagai contoh, menghitung kemiripan kata antara kata benda kalimat A dengan himpunan gabungan kata benda. Tahap ini akan didapatkan vektor semantik kata benda kalimat A. Hal yang sama juga diberlakukan untuk kata kerja dengan himpunan gabungan kata kerja. Vektor semantik kata benda dan vektor semantik kata kerja masing-masing dinotasikan dengan N V dan V V . Setelah vektor semantik kata benda dan vektor semantik kata kerja

36 dari kedua kalimat didapatkan, menghitung cosine similarity kedua vektor semantik tersebut. Hasil yang diperoleh berupa nilai consine similarity kata benda, N CA,B , dan kata kerja, V CA,B . Nilai tersebut didapatkan melalui Persamaan 2.2 dan 2.3: ( )2 N⃗VA · N⃗VB N CA,B = ∥ N⃗VA ∥ × ∥ N⃗VB ∥  2 ∑|S_NA ∪S_NB | N VAi × N VBi i=1  √∑ =  √∑ |S_NA ∪S_NB | |S_NA ∪S_NB | 2 2 N V × N V Ai Bi i=1 i=1 (2.2) ( V CA,B = 

V ⃗VA · V ⃗VB ∥ V ⃗VA ∥ × ∥ V ⃗VB ∥

=  √∑

)2

∑|S_VA ∪S_VB | i=1

|S_VA ∪S_VB | i=1

V

VA2i

2

V VAi × V VBi  √∑ |S_VA ∪S_VB | 2 × V V Bi i=1 (2.3)

Hasil kedua nilai cosine similarity digunakan untuk menghitung nilai akhir kemiripan semantik kalimat. Nilai tersebut didapatkan dari nilai N CA,B dan V CA,B melalui Persamaan 2.4: SimilarityA,B = ζ × (N CA,B ) + (1 − ζ) × (V CA,B )

(2.4)

di mana, koefisien ζ adalah koefisien untuk menyeimbangkan bobot N C dan V C. Koefisien ini ditentukan berdasarkan percobaan atau peneliti secara manual. Nilai koefisien ζ diambil pada rentang 0 hingga 1. Terakhir, perhitungan kemiripan semantik kalimat didasarkan pada metode yang diajukan oleh Mihalcea et al. [15]. Metode ini menggabungkan nilai kemiripan semantik kata dengan nilai bobot kata. Misal, terdapat kalimat s1 dan s2 , perhitungan kemiripan kalimat dihitung dengan menemukan nilai kemiripan kata tertinggi untuk setiap kata s1 dengan kata yang memiliki part-of-speech yang sama di s2 . Kemudian, cara yang sama dilakukan untuk setiap kata s2 dengan kata yang memiliki part-of-speech

37 yang sama di s1 . Kemiripan juga dibobotkan dengan nilai idf dari kata yang bersesuaian. Sehingga, persamaan kemiripan semantik didefinisikan oleh Persamaan 2.5: ∑ (max Sim(w,s2 ) × idf (w)) 1 w∈s1 simsem,IDF (s1 ,s2 ) = ( + ∑ 2 idf (w) ∑ w∈s2

w∈s1

(2.5)

(max Sim(w,s1 ) × idf (w)) ∑

) idf (w)

w∈s2

di mana, maxSim(w,si ) adalah nilai maksimum kemiripan semantik dari w dan kata dalam si yang memiliki kelas kata yang sama. Sementara, idf adalah inverse document frequency dari w.

2.8.2 Kemiripan Sintaksis Kalimat (Word Order Similarity) Sintaksis atau susunan kata juga memiliki peran penting dalam kalimat karena menyediakan informasi untuk membedakan makna antara dua kalimat. Tanpa informasi ini, tidak bisa membedakan kalimat yang memiliki representasi bag-of-word atau sebuah himpunan kata yang mirip. Contoh, kalimat “Bob calls Alice.” dan “Alice calls Bob.”. Dua kalimat tersebut mirip namun memiliki makna sangat berbeda. Perhitungan kemiripan susunan kata didefinisikan sebagai normalisasi selisih susunan kata antara dua kalimat [13]. Definisi tersebut ditunjukkan pada Persamaan 2.6: ∥r1 − r2 ∥ simwo (s1 ,s2 ) = 1 − (2.6) ∥r1 + r2 ∥ Di mana, r1 dan r2 adalah sebuah vektor susunan kata dari kalimat s1 dan s2 . Vektor susunan kata adalah sebuah vektor yang terdiri kumpulan fitur dari kata yang muncul pada sebuah pasangan kalimat. Posisi indeks kata pada kalimat yang bersesuaian digunakan untuk pembobotan kata. Setiap elemen vektor susunan kata ri berasal dari nilai perhitungan kemiripan kata antara sebuah fitur kata w dengan semua kata pada kalimat si . Posisi indeks kata pada si menunjukkan nilai maksimum kemiripan kata dengan memilih w sebagai bobot katanya.

38

2.8.3

Kombinasi Semantik dan Sintaksis Kalimat

Pendekatan kemiripan kalimat lainnya adalah menggabungkan informasi semantik dan sintaksis dari kalimat. Pendekatan ini juga memiliki peran penting dalam memahami sebuah kalimat. Kemiripan suatu kalimat adalah kombinasi linear antara kemiripan vektor semantik (semantic vector) dan susunan kata (word order). Hasil perhitungan kombinasi ini dipengaruhi oleh suatu koefisien alpha (α) sebesar 0.8. Nilai ini telah dibuktikan oleh penelitian [13]. Perhitungan dengan pendekatan ini ditunjukkan oleh Persamaan 2.7: simssv+wo (s1 ,s2 ) = αsimssv (s1 ,s2 ) + (1 − α)simwo (s1 ,s2 )

(2.7)

Nilai hasil perhitungan dari pendekatan kemiripan semantik, sintaksis, dan kombinasi semantik-sintaksis kalimat berada pada rentang 0 hingga 1. Nilai 0 berarti dua kalimat tidak sama, sedangkan nilai 1 berarti sama (identik). Jika nilai berada pada rentang 0 dan 1, dua kalimat memiliki kemiripan dari tidak mirip hingga mirip.

2.9

WordNet

WordNet [16] adalah sebuah basis data leksikal bahasa Inggris. Kata benda (noun), kata kerja (verb), kata sifat (adjective), dan kata keterangan (adverb) dikelompokkan ke dalam sebuah kumpulan cognitive synonyms yang disebut synsets. Synsets saling terkait atau concept dihubungkan dengan conceptual-semantic dan hubungan leksikal. Sebuah concept merepresentasikan sekumpulan entitas yang memiliki karateristik yang sama. Sebagai gambaran, programmer, software engineer, dan coder merupakan contoh concept dari engineer. WordNet berbeda dengan kamus umum yang mendeskripsikan makna suatu kata dan mengelompokkan kata sesuai urutan abjad. WordNet mengelompokkan suatu kata berdasarkan maknanya. Kata yang berdekatan memiliki makna yang berhubungan. Hubungan tersebut berupa hubungan semantik antar synsets. Misal, hubungan kata “programmer” dengan kata “software engineer” pada konteks kata benda (noun sense). Hubungan tersebut bisa digambarkan melalui Gambar 2.4. Synsets “programmer” dan synsets “software engineer” dihubungkan oleh concept “engineer”. Keduanya sama-sama memiliki satu synsets yang terdiri dari satu

39 entity physical-entity object whole living-thing being

organism person

individual

engineer

...

...

programmer,software-engineer,coder,... Gambar 2.4 Potongan hubungan semantik pada WordNet noun sense apabila dicari pada WordNet3 . Oleh sebab itu, synsets tersebut memiliki makna yang sama. Programmer dan software engineer bermakna a person who designs and writes and tests computer programs.

2.10 Perhitungan Kemiripan Kata Sesuai dengan penjelasan sebelumnya, hubungan semantik antar kata menentukan kemiripan semantik kalimat. Hubungan tersebut dapat digunakan untuk menghitung kemiripan semantik antar kata. Kemiripan semantik antar kata berbeda dengan pencocokan kata (string similarity) 3

Kata di dalam WordNet dapat dicari melalui laman http://wordnetweb.

princeton.edu/perl/webwn.

40

Gambar 2.5 Metrik knowledge-based similarity

yang menghitung kemiripan berdasarkan perubahan karakter antar kata. Kemiripan semantik kata menghitung nilai kemiripan berdasarkan derajat kemiripan antar kata melalui informasi yang didapatkan dari jaringan semantik [15] karena merupakan salah satu pendekatan knowledge-based similarity. WordNet merupakan basis data leksikal yang sangat populer untuk menghitung knowledge-based similarity. Ada banyak jenis metrik perhitungan kemiripan semantik kata dengan menggunakan WordNet [17]. Metrik tersebut dibagi ke dalam dua kategori yang ditunjukkan oleh Gambar 2.5. Knowledge-based similarity terdiri dari semantic similarity dan semantic relatedness. Semantic similarity melihat hubungan kata berdasarkan kemiripan concept, sedangkan semantic relatedness lebih tidak terikat pada concept. Semantic similarity memiliki hubungan antar kata yang lebih luas dibandingkan semantic relatedness. Hubungan tersebut, seperti is-a-kind-of, is-a-part-of, dan is-a-specific-example-of [18]. Oleh sebab

41 itu, bagian selanjutnya hanya menjelaskan metrik-metrik perhitungan semantic similarity. Masing-masing metrik perhitungan tersebut dijelaskan sebagai berikut:

2.10.1 Leacock-Chodorow Perhitungan kemiripan kata dengan metrik Leacock-Chodorow [19] didasarkan pada panjang path terdekat di antara dua concept, c1 dan c2 , dalam struktur taksonomi. Perhitungan ditunjukkan oleh Persamaan 2.8: simlch (c1 ,c2 ) = − log

length(c1 ,c2 ) 2×D

(2.8)

di mana, length adalah panjang path terdekat di antara dua concept dan D adalah nilai maksimum kedalaman dari taksonomi. Metrik ini terbatas pada dua concept yang berada pada is-a taksonomi. Hubungan is-a digunakan untuk mendeskripsikan hubungan antara hipernim dengan hiponim. Contoh hiponim dari bird, seperti pigeon, crow, dan eagle. Bird sendiri merupakan hipernim. Hipernim juga bisa disebut sebagai superconcept.

2.10.2 Wu-Palmer Perhitungan kemiripan dengan Wu-Palmer [20] dihitung berdasarkan kedalaman (depth) dua concept, c1 dan c2 , pada struktur taksonomi dan kedalaman least common subsumer (LCS). LCS adalah node terendah dari dua node yang merupakan anak (child) dari node terendah tersebut. Perhitungan ditunjukkan oleh Persamaan 2.9: simwup (c1 ,c2 ) =

2 × depth(LCS(c1 ,c2 )) depth(c1 ) + depth(c2 )

(2.9)

2.10.3 Path Perhitungan kemiripan kata dengan Path dihitung berdasarkan path terpendek yang menghubungkan dua concept pada is-a taksonomi. Perhitungan dengan metrik ini sangat sederhana. Perhitungan ditunjukkan oleh Persamaan 2.10: simpath (c1 ,c2 ) =

1 length(c1 ,c2 )

(2.10)

42 di mana, length adalah panjang path terpendek yang menghubungkan dua concept.

2.10.4

Resnik

Resnik [21] mengenalkan information content (IC) sebagai perhitungan kemiripan kata. IC digunakan untuk menghitung seberapa informatif concept-concept. Perhitungan kemiripan antara dua concept dengan metrik ini ditunjukkan oleh Persamaan 2.11: simres = IC(LCS(c1 ,c2 ))

(2.11)

di mana, IC didefinisikan sebagai: IC(c) = − log P (c)

(2.12)

dan P (c) adalah probabilitas ditemukannya sebuah contoh concept c dalam sebuah corpus, sebuah kumpulan teks yang sangat besar dan terstruktur. IC sendiri memiliki model untuk menghitung nilai P (c). Model tersebut, di antaranya Seco et al. [22], Zhou et al. [23], Sánchez et al. [24], dan Meng et al. [25]. Masing-masing model IC memiliki paratemer yang berbeda dalam perhitungan. Parameter yang dimaksud, seperti kedalaman node dan leaf (node yang tidak memiliki child node).

2.10.5

Lin

Perhitungan kemiripan dengan pendekatan Lin [26] didasarkan pada perhitungan kemiripan Resnik dengan menambahkan sebuah faktor normalisasi information content di antara dua concept. Perhitungan ditunjukkan oleh Persamaan 2.13: simlin =

2.10.6

2 × IC(LCS(c1 ,c2 )) IC(c1 ) + IC(c2 )

(2.13)

Jiang-Conrath

Jiang-Conrath [27] menghitung kemiripan antara dua concept dengan menggunakan information content. Namun, information content tersebut dalam bentuk probabilitas bersyarat ditemukannya sebuah contoh

43 child-synset dengan diberikan sebuah contoh parent synset. Perhitungan ditunjukkan oleh Persamaan 2.14: simjch =

1 IC(c1 ) + IC(c2 ) − 2 × IC(LCS(c1 ,c2 ))

(2.14)

Enam pendekatan kemiripan kata di atas merupakan metrik-metrik yang menghitung kemiripan kata berdasarkan concept-to-concept. Kemiripan kata dengan nilai tertinggi dari pasangan kata menunjukkan kedekatan makna pasangan tersebut. Nilai hasil perhitungan kemiripan kata untuk metrik Wu-Palmer dan Lin berada pada rentang 0 hingga 1, sedangkan metrik Path, Leacock-Chodorow, Resnik, dan Jiang-Conrath berada pada rentang 0 hingga tak hingga (infinity). Normalisasi hasil perhitungan diperlukan agar metrik-metrik tersebut menghasilkan nilai di antara 0 hingga 1. Normalisasi dapat dilakukan dengan membagi nilai perhitungan salah satu metrik dengan skor tertinggi dari kata pertama yang dibandingkan. Contoh, perhitungan kemiripan antara kata w1 dan w2 dengan metrik Leacock-Chodorow dinormalisasi dengan Persamaan 2.15: simlch (w1 ,w2 ) =

simlch (w1 ,w2 ) simlch (w1 ,w1 )

(2.15)

Tugas Akhir ini menggunakan metrik Lin untuk menghitung kemiripan semantik antar kata. Metrik ini memiliki nilai korelasi yang tinggi dibanding metrik lain yang telah dibahas sebelumnya [28, 29]. Untuk mendapatkan nilai kemiripan semantik kata dengan metrik tersebut, pustaka Slib [30] dapat digunakan. Pustaka ini mengimplementasikan metrik kemiripan semantik kata dengan menggunakan jaringan semantik yang mana salah satunya adalah WordNet.


BAB III ANALISIS DAN PERANCANGAN SISTEM

Bab ini membahas analisis dan perancangan dari perangkat lunak yang hendak dibangun melalui pendekatan berorientasi objek. Analisis membahas pendefinisian kebutuhan sistem terhadap permasalahan yang diangkat di dalam Tugas Akhir ini. Selanjutnya, perancangan membahas perancangan antarmuka dan proses yang ada di dalam perangkat lunak.

3.1 Analisis Perangkat Lunak Subbab ini membahas analisis kebutuhan perangkat lunak. Analisis perangkat lunak secara garis besar berisi deskripsi umum dan kebutuhan perangkat lunak.

3.1.1 Deskripsi Umum Perangkat Lunak Tugas Akhir ini dibuat sebuah perangkat lunak untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). Perangkat lunak yang dibuat berupa kakas bantu berbasis desktop. Adapun pengguna dari kakas bantu ini, yaitu analis sistem, peran yang memiliki tanggung jawab untuk menjembatani pengguna dan pengembang dalam sebuah proyek perangkat lunak. Gambaran proses dari kakas bantu yang dibuat adalah sebagai berikut: • Pra-proses: analis sistem merancang diagram kasus penggunaan beserta deskripsi kasus penggunaan (use case description) dan diagram urutan menggunakan aplikasi StarUML 2. Kemudian, analis sistem mengonversikan hasil rancangan tersebut menjadi sebuah berkas dalam format “.xmi” menggunakan bantuan XMI extension StarUML 2. Berkas XMI yang dihasilkan selanjutnya disebut dengan dokumen rancangan. • Input: dokumen rancangan yang berisi diagram kasus penggunaan, deskripsi kasus penggunaan, dan diagram urutan dalam format “.xmi”. • Proses: mengekstraksi dokumen rancangan yang terdiri dari ekstraksi deskripsi kasus penggunaan untuk mendapatkan kalimat alur kejadian dasar (basic flow) serta diagram urutan untuk mendapatkan triplet yang terdiri dari nama aktor, nama method, dan nama boundary class atau nama kelas yang mengirim method ke boundary class, nama method, dan nama boundary class. Kemudian, pengelompokan hasil ekstraksi

45

46 berdasarkan nama kasus penggunaan (use case). Pengelompokan ini menghasilkan kumpulan kalimat alur kejadian dasar dan triplet. Hasil pengelompokan digunakan sebagai bahan mendeteksi ketidaksesuaian. Deteksi ketidaksesuaian dimulai dengan mengambil satu kasus penggunaan terlebih dahulu. Deteksi ketidaksesuaian dimulai dengan menemukan pasangan kasus penggunaan dengan diagram urutannya. Jika tidak ditemukan, kakas bantu menampilkan pesan bahwa pasangan tersebut tidak ditemukan. Jika ditemukan, menghitung kesesuaian pasangan kalimat alur kejadian dasar dengan triplet kasus penggunaan tersebut. Perhitungan kesesuaian dihitung dengan menghitung kemiripan semantik kalimat. Nilai hasil perhitungan kemiripan kalimat yang memenuhi ambang batas yang telah ditentukan menentukan nilai kesesuaian. Perhitungan kesesuaian dilanjutkan oleh kasus penggunaan berikutnya apabila satu kasus penggunaan telah selesai dideteksi. Setiap hasil perhitungan kesesuaian pasangan kalimat alur kejadian dasar dengan triplet disimpan. • Output: berupa daftar yang berisi yang nama kasus penggunaan, kalimat alur kejadian dasar, dan triplet, dengan penanda kesesuaian (“Sesuai” atau “Tidak sesuai”). Selain itu, hasil deteksi bisa dieskpor ke bentuk laporan dalam format “.doc”, “.docx”, atau “.pdf”.

3.1.2

Proses Bisnis

Proses bisnis yang ditangkap pada kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram) dijelaskan oleh deskripsi berikut: Nama Alur

: :

Masukan

:

Memeriksa ketidaksesuaian dokumen rancangan 1. Memasukkan dokumen rancangan. 2. Memilih pilihan apakah hasil deteksi ketidaksesuaian akan dieskpor ke bentuk laporan. 3. Menjalankan pemeriksaan ketidaksesuaian dokumen rancangan. 4. Mendapatkan hasil deteksi ketidaksesuaian dokumen rancangan. Dokumen rancangan yang berisi diagram kasus penggunaan beserta deskripsi kasus penggunaan (use case description) dan diagram urutan.

47 Keluaran

:

Pelaku

:

Informasi dalam bentuk daftar atau laporan yang berisi nama kasus penggunaan (use case), kalimat alur kejadian dasar (basic flow), triplet, dan penanda kesesuaian (“Sesuai” atau “Tidak sesuai”). Analis sistem

3.1.3 Fungsi Produk Proses bisnis yang telah dijelaskan sebelumnya kemudian dipetakan ke dalam fungsi produk. Fungsi produk ini merupakan kebutuhan fungsional yang harus dipenuhi oleh kakas bantu. Pemetaan tersebut dijabarkan oleh deskripsi berikut: Nama Proses Bisnis

:

Fungsi Produk

:

Asumsi

:

Memeriksa ketidaksesuaian dokumen rancangan • Kakas bantu dapat mendeteksi ketidaksesuaian dokumen rancangan yang dimasukkan. • Kakas bantu dapat menampilkan hasil deteksi ketidaksesuaian dokumen rancangan atau mengekspor hasil tersebut ke bentuk laporan. Dokumen rancangan dalam format “.xmi” dan laporan hasil deteksi dalam format “.doc”, “.docx”, atau “.pdf”.

Dari pemetaan tersebut di atas, ada dua kebutuhan fungsional yang dibutuhkan oleh analis sistem pada kakas bantu. Kebutuhan fungsional tersebut adalah analis sistem dapat memeriksa ketidaksesuaian dokumen rancangan dan mendapatkan hasil pemeriksaan ketidaksesuaian.

3.1.4 Karakteristik Pengguna Pengguna kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram) adalah analis sistem. Analis sistem memiliki tanggung jawab untuk menerjemahkan kebutuhan client ke dalam sebuah rancangan. Salah satu kegiatan yang dilakukan analis sistem selama iterasi pengembangan perangkat lunak adalah memeriksa rancangan diagram urutan dengan

48 diagram kasus penggunaan. Analis sistem memiliki hak untuk memasukkan dan memeriksa dokumen rancangan yang telah dibuat ke dalam kakas bantu. Tambahan, kemampuan memahami konsistensi rancangan diagram urutan dengan diagram kasus penggunaan harus dimiliki oleh analis sistem.

3.1.5

Batasan

Adapun batasan dari kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). Batasan terkait metode dan teknologi yang digunakan saat implementasi perangkat lunak. Batasan tersebut antara lain: 1. Kakas bantu ini merupakan aplikasi berbasis desktop. 2. Kakas bantu dibuat dengan menggunakan bahasa pemrograman Java. 3. Kakas bantu hanya dapat membaca dokumen rancangan dalam format “.xmi” yang dihasilkan oleh aplikasi pemodelan StarUML 2. 4. Kakas bantu dapat mengekspor hasil pemeriksaan ketidaksesuaian ke bentuk laporan dalam format “.doc”, “.docx”, atau “.pdf”.

3.1.6

Kebutuhan Non-fungsional

Adapun kebutuhan non-fungsional yang dibutuhkan dalam kakas bantu ini. Kebutuhan non-fungsional menjelaskan atribut-atribut pendukung apa saja yang harus dimiliki oleh perangkat lunak. Kebutuhan ini juga mendukung kebutuhan fungsional. Kebutuhan non-fungsional dari kakas bantu ini hanya satu, yaitu atribut usability. Penjelasan atribut ini dijelaskan sebagai berikut. Atribut Deskripsi

: :

Usability Kakas bantu mudah untuk dipelajari dan digunakan oleh pengguna saat menggunakan fungsi utama sistem. Atribut ini meliputi waktu yang dibutuhkan pengguna untuk mempelajari kakas bantu, informasi atau nama perintah yang mudah dipahami, dan respon kakas bantu ketika diberikan sebuah perintah.

49

3.1.7 Diagram Kasus Penggunaan (Use Case Diagram) Kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram) memiliki fungsionalitas utama untuk memeriksa ketidaksesuaian dokumen rancangan. Fungsionalitas tersebut diterjemahkan ke dalam diagram kasus penggunaan. Kasus penggunaan (use case) merepresentasikan fungsionalitas (kebutuhan utama) yang dibutuhkan oleh aktor. Diagram kasus penggunaan dari kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram) ditunjukkan pada Gambar 3.1. Gambar 3.1 menunjukkan ada satu kasus penggunaan utama (base use case) dari kakas bantu, yaitu memeriksa ketidaksesuaian dokumen rancangan. Penjelasan lebih dalam dari kasus penggunaan ini dijelaskan pada bagian berikutnya.

Gambar 3.1 Diagram kasus penggunaan (use case diagram) kakas bantu Bagaimana analis sistem melakukan pemeriksaan ketidaksesuaian dokumen rancangan dijelaskan oleh kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”. Kasus penggunaan ini memiliki subkasus penggunaan (sub-use case), yaitu mengekspor laporan hasil pemeriksaan ketidaksesuaian. Seperti yang telah disebutkan sebelumnya, analis sistem dapat mendapatkan hasil pemeriksaan ketidaksesuaian dokumen rancangan dalam bentuk laporan. Kasus penggunaan tersebut merupakan

50 titik ektensi dari kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”. Titik ekstensi suatu kasus penggunaan dinotasikan dengan relasi extend. Relasi extend menunjukkan hubungan antara kasus penggunaan utama dengan sub-kasus penggunaan yang bersifat pilihan (optional).

Gambar 3.2 Kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” Gambar 3.2 menunjukkan relasi extend antara kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” dengan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian”. Setiap kasus penggunaan memiliki deskripsi berupa alur berupa dialog antara aktor dan sistem. Alur tersebut disebut dengan alur dasar (basic flow). Alur dasar dari kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” dijabarkan sebagai berikut: 1. Analis sistem menekan tombol “Masukan berkas...” pada layar utama kakas utama. 2. Kakas bantu menampilkan jendela “Masukan berkas dokumen rancangan” untuk memilih lokasi di mana dokumen rancangan disimpan. 3. Analis sistem memilih dokumen rancangan pada lokasi di mana dokumen rancangan disimpan. 4. Analis sistem menekan tombol “Open” pada jendela “Masukan berkas dokumen rancangan”. 5. Kakas bantu menampilkan lokasi dokumen rancangan yang telah dipilih pada kolom masukan berkas. 6. Analis sistem menekan tombol “Lakukan deteksi” pada layar utama kakas bantu. 7. Kakas bantu menampilkan hasil deteksi ketidaksesuaian pada layar uta-

51 ma kakas bantu. Kemudian, alur dari sub-kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” yang merupakan perluasan dari kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” terjadi pada alur nomor 4 dari alur dasar kasus penggunaan tersebut. Alur dari sub-kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” dijabarkan sebagai berikut: 4a.1 Analis sistem mencentang opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” pada layar utama kakas bantu. 4a.2 Analis sistem menekan tombol “Simpan hasil...”. 4a.3 Kakas bantu menampilkan jendela untuk memilih lokasi di mana laporan hasil pemeriksaan ketidaksesuaian akan disimpan. 4a.4 Analis sistem memilih lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian. 4a.5 Analis sistem memilih jenis format laporan hasil deteksi ketidaksesuaian rancangan. 4a.6 Analis sistem memasukkan nama berkas laporan hasil pemeriksaan ketidaksesuaian. 4a.7 Analis sistem menekan tombol “Save”. 4a.8 Kakas bantu menampilkan lokasi penyimpanan hasil deteksi pada layar utama kakas bantu. Penjelasan di atas merupakan bagian dari spesikasi kasus penggunaan (use case specification) dari kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”. Bagian lebih lengkap dari spesifikasi kasus penggunaan tersebut dapat dilihat pada Lampiran A. Spesifikasi kasus penggunaan disusun sesuai dengan template yang disediakan oleh RUP (Rational Unified Process).

3.1.8 Diagram Aktivitas (Activity Diagram) Diagram aktivitas adalah diagram yang digunakan untuk menggambarkan proses bisnis atau urutan aktivitas dalam sebuah proses. Diagram ini juga bisa digunakan untuk menjelaskan langkah-langkah bagaimana suatu kasus penggunaan (use case) dijalankan. Alur dasar (basic flow) yang telah dijabarkan pada subbab penjelasan kasus penggunaan sebelumnya kemudian direpresentasikan ke dalam diagram aktivitas. Diagram tersebut di antaranya sebagai berikut:

52

3.1.8.1

Diagram Aktivitas: Memeriksa Ketidaksesuaian Dokumen Rancangan

Diagram aktivitas untuk kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” digambarkan oleh Gambar 3.3. Terdapat angka di dalam lingkaran pada setiap aktivitas. Angka tersebut berkorespondensi dengan nomor pada alur dasar kasus penggunaan.

Gambar 3.3 Diagram aktivitas (activity diagram) kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”

53

3.1.8.2 Diagram Aktivitas: Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian Diagram aktivitas untuk kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” digambarkan oleh Gambar 3.4. Tidak berbeda dengan diagram aktivitas sebelumnya, angka di dalam lingkaran pada setiap aktivitas merujuk ke nomor alur kasus penggunaan.

Gambar 3.4 Diagram aktivitas (activity diagram) kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian”

54

3.1.9

Kelas Analisis

Diagram kasus penggunaan (use case diagram) yang telah digambarkan sebelumnya akan menjadi bahan model analisis. Model analisis diperlukan untuk menemukan kelas-kelas analisis pada setiap kasus penggunaan (use case). Selain itu, model analisis menghasilkan spesifikasi kebutuhan yang lebih tepat dan lengkap. Penjelasan alur setiap kasus penggunaan dilengkapi terlebih dahulu sebelum melakukan model analisis. Sesuai Gambar 3.1, terdapat dua kasus penggunaan, yaitu memeriksa ketidaksesuaian dokumen rancangan dan mengekspor laporan hasil pemeriksaan ketidaksesuaian. Proses model analisis kasus penggunaan tersebut dijelaskan secara detail pada subbab berikut:

3.1.9.1

Kelas Analisis Memeriksa Ketidaksesuaian Dokumen Rancangan

Kasus penggunaan ini dilakukan oleh seorang aktor, yaitu analis sistem. Setelah analis sistem merancang diagram, analis sistem melakukan pemeriksaan rancangan tersebut untuk mengetahui apakah rancangan sudah sesuai atau belum. Analis sistem menyimpan dokumen rancangan pada perangkat penyimpanan. Perangkat penyimpanan bisa berupa penyimpanan internal dan eksternal komputer. Dokumen rancangan yang disimpan adalah rancangan diagram yang berisi diagram kasus penggunaan (use case diagram), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram). Model analisis kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” dilakukan melalui langkah-langkah berikut ini: 1. Melengkapi penjelasan kasus penggunaan (use case) Berdasarkan alur dasar kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”, kasus penggunaan ini dimulai saat analis sistem menekan tombol “Masukan berkas...”. Layar utama kakas bantu mengirimkan perintah untuk menampilkan jendela “Masukan berkas dokumen rancangan”. Jendela tersebut digunakan untuk memilih lokasi di mana dokumen rancangan disimpan. Analis sistem mencari lokasi di mana dokumen rancangan disimpan pada jendela “Masukan berkas dokumen rancangan”. Setelah lokasi dokumen rancangan ditemukan, analis sistem memilih dokumen rancangan tersebut dan menekan tombol “Open”. Layar utama kakas bantu mengambil alamat

55 berkas dokumen rancangan (file path) untuk dilakukan pengecekan format. Format berkas dokumen rancangan adalah “.xmi”. Jika format tidak sesuai, layar utama kakas bantu memberikan sebuah pesan peringatan bahwa format dokumen rancangan yang dimasukkan tidak sesuai. Jika sesuai, layar utama kakas bantu menampilkan alamat berkas dokumen rancangan tersebut pada kolom masukan berkas. Analis sistem menekan tombol “Lakukan deteksi” untuk memulai pemeriksaan ketidaksesuaian dokumen rancangan. Layar utama kakas bantu mengirimkan perintah untuk melakukan pemeriksaan ketidaksesuaian. Pemeriksaan ketidaksesuaian dilakukan dengan mengekstraksi berkas dokumen rancangan terlebih dahulu. Untuk setiap kasus penggunaan (use case), ekstraksi deskripsi kasus penggunaan (use case description) untuk mendapatkan kalimat alur kejadian dasar (basic flow) serta diagram urutan (sequence diagram) untuk mendapatkan triplet yang terdiri dari nama aktor, nama method, dan nama boundary class atau nama control class, nama return method yang dikirim oleh control class ke boundary class, dan nama boundary class. Kemudian, pengelompokan hasil ekstraksi berdasarkan nama kasus penggunaan. Pengelompokan ini menghasilkan pasangan kalimat alur kejadian dasar serta triplet yang bersesuaian dengan nama kasus penggunaannya. Pemeriksaan ketidaksesuaian dilanjutkan dengan memeriksa satu kasus penggunaan terlebih dahulu. Pemeriksaan menggunakan metode perhitungan kemiripan semantik kalimat dengan menghitung kemiripan antara kalimat alur kejadian dasar dengan triplet. Perhitungan dimulai dengan mengubah bentuk triplet menjadi kalimat. Kemudian, melakukkan tagging untuk mengetahui part-of-speech (POS) dari sebuah kalimat. Hasil tagging digunakan untuk perhitungan kemiripan semantik kata. Perhitungan dilakukan pada kata yang memiliki penanda POS yang sama pada kalimat alur kejadian dasar dan triplet. Tambahan, perhitungan ini dibantu dengan basis data leksikal WordNet untuk mengetahui kemiripan semantik antar kata. Hasil perhitungan ini kemudian dihitung menggunakan metode yang telah dipilih untuk mendapatkan skor kemiripan kedua kalimat tersebut. Jika skor memenuhi ambang batas (threshold) yang telah ditentukan maka hasil deteksi diberikan label “Sesuai”. Jika tidak, perhitungan dilakukan hingga pasangan triplet terakhir. Label “Tidak sesuai” diberikan jika skor pasangan tidak memenuhi ambang batas yang telah ditentukan. Setiap hasil deteksi tersebut disimpan. Pemeriksaan ketidaksesuaian dilanjutkan dengan kasus

56 penggunaan berikutnya. Hasil pemeriksaan ketidaksesuaian berupa informasi yang terdiri dari nama kasus penggunaan, daftar kalimat alur kejadian dasar kasus penggunaan, dan daftar triplet dengan penanda kesesuaian. Hasil ini ditampilkan pada layar utama kakas bantu. 2. Untuk setiap realisasi kasus penggunaan (use case): 2.1. Menemukan kandidat kelas dari perilaku kasus penggunaan (use case) Alur kasus penggunaan yang telah dilengkapi penjelasannya kemudian dianalisis perilakunya untuk mendapatkan kelas. Kandidat kelas bisa ditemukan melalui pemilihan kata benda pada alur tersebut. Tabel 3.4 menunjukkan kandidat kelas hasil analisis melalui pendekatan kata benda.

Tabel 3.4 Kandidat kelas kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” No.

Kandidat

Pengertian

Kelas?

Penjelasan

1

Analis sistem

Bukan

Analis sistem merupakan pengguna dari kakas bantu ini. Data analis sistem yang menggunakan kakas bantu tidak diproses di dalam sistem.

2

Tombol “Masukan berkas...”

Peran yang memiliki tanggung jawab untuk menjembatani pengguna dan pengembang dalam sebuah proyek perangkat lunak. Tombol yang digunakan untuk memasukkan dokumen rancangan.

Bukan

Tombol ini merupakan salah satu komponen penyusun (atribut) layar utama kakas bantu.

57 Tabel 3.4 Kandidat kelas kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” (lanjutan) No.

Kandidat

Pengertian

Kelas?

3

Layar utama kakas bantu

Ya

4

Jendela “Masukan berkas dokumen rancangan”

Antarmuka utama kakas bantu yang menghubungkan analis sistem dengan kakas bantu (tempat proses bisnis berlangsung). Jendela untuk memilih dokumen rancangan yang disimpan pada lokasi tertentu.

5

Dokumen rancangan

Dokumen yang berisi diagram kasus penggunaan (use case diagram), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram) dalam format XMI.

Bukan

Ya

Penjelasan Layar kakas bantu terdiri dari komponenkomponen seperti, tombol “Masukkan berkas...”, kolom masukan berkas, dan tombol “Lakukan deteksi...”. Jendela ini merupakan antarmuka yang menangani pemilihan berkas, seperti menampilkan lokasi di mana berkas disimpan, mengatur jenis ekstensi berkas yang bisa dipilih, dan memilih berkas. Dokumen rancangan tidak disimpan dan tidak diubah isinya (hanya untuk membaca dan mengekstraksi elemen diagram yang diperlukan).


Kandidat

Pengertian

Kelas?

Penjelasan

6

Lokasi dokumen rancangan

Bukan

7

Tombol “Open”

Lokasi dokumen rancangan merupakan informasi yang dibutuhkan untuk membaca isi dokumen rancangan. Tombol ini merupakan salah satu komponen penyusun (atribut) layar utama kakas bantu.

8

Alamat berkas dokumen rancangan

9

Format berkas dokumen rancangan

Lokasi yang berisi alamat berkas dari dokumen rancangan yang dimasukkan ke kakas bantu. Tombol yang digunakan untuk memilih berkas dokumen rancangan yang dipilih dari jendela “Masukkan berkas”. Alamat yang berisi file path dari dokumen rancangan yang dimasukkan ke kakas bantu Format yang berisi identitas sebuah berkas, seperti extension berkas dokumen rancangan adalah “.xmi”.

Bukan

Bukan

Bukan

Alamat berkas dokumen rancangan merupakan informasi yang dibutuhkan untuk membaca isi dokumen rancangan. Format berkas dokumen rancangan merupakan informasi yang digunakan untuk mengecek apakah format dokumen rancangan yang dimasukkan sudah sesuai atau belum.


Kandidat

Pengertian

Kelas?

Penjelasan

10

Pesan peringatan

Bukan

11

Kolom masukan berkas

12

Tombol “Lakukan deteksi...”

Pesan peringatan merupakan hasil pemanggilan perintah pada layar utama kakas bantu. Kolom ini merupakan salah satu komponen penyusun (atribut) layar utama kakas bantu. Tombol ini merupakan salah satu komponen penyusun (atribut) layar utama kakas bantu.

13

Pemeriksaan ketidaksesuaian

Antarmuka yang menampilkan sebuah pesan, seperti pesan kesalahan. Kolom yang berisi alamat di mana berkas dokumen rancangan disimpan. Tombol yang digunakan untuk melakukan pemeriksaan ketidaksesuaian dokumen rancangan yang telah dimasukkan ke kakas bantu. Proses untuk memeriksa ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram).

Bukan

Bukan

Ya

Pemeriksaan ketidaksesuaian mengatur deteksi ketidaksesuaian mulai dari ekstraksi dokumen rancangan hingga menampilkan hasil pemeriksaan ketidaksesuaian.


Kandidat

Pengertian

Kelas?

Penjelasan

14

Kasus penggunaan (use case)

Deskripsi dari interaksi aktor dan sistem yang ditujukan untuk memenuhi kebutuhan pengguna.

Bukan

15

Deskripsi kasus penggunaan (use case description)

Bukan

16

Diagram urutan (sequence diagram)

Deskripsi singkat dari sebuah kasus penggunaan yang berisi nama kasus penggunaan, aktor yang melakukan, dan alur untuk mencapai kasus penggunaan tersebut. Diagram yang menggambarkan interaksi antara objek-objek suatu sistem melalui rangkaian urutan pesan (message).

Kasus penggunaan merupakan elemen diagram hasil ekstraksi dokumen rancangan yang diperlukan untuk pemeriksaan ketidaksesuaian. Elemen diagram ini tidak disimpan, hanya diproses. Deskripsi kasus penggunaan merupakan elemen diagram hasil ekstraksi dokumen rancangan yang diperlukan untuk pemeriksaan ketidaksesuaian. Elemen diagram ini tidak disimpan, hanya diproses. Diagram urutan merupakan elemen diagram hasil ekstraksi dokumen rancangan yang diperlukan untuk pemeriksaan ketidaksesuaian. Elemen diagram ini tidak disimpan, hanya diproses.

Bukan


Kandidat

Pengertian

Kelas?

Penjelasan

17

Kalimat alur kejadian dasar (basic flow) kasus penggunaan

Kalimat yang berisi alur dasar kasus penggunaan dalam bentuk dialog antara aktor dan sistem.

Bukan

18

Triplet

Bukan

19

Nama aktor

20

Nama method

21

Nama boundary class

Kelompok yang terdiri dari nama aktor, nama method, dan nama boundary class dari sebuah diagram urutan (sequence diagram). Nama aktor pada lifeline diagram urutan. Nama method yang dikirim atau diterima oleh lifeline pada diagram urutan. Nama boundary class pada lifeline diagram urutan.

Kalimat ini merupakan kalimat hasil ekstraksi dokumen rancangan yang diperlukan untuk pemeriksaan ketidaksesuaian. Kalimat alur kejadian dasar tidak disimpan, hanya diproses. Triplet merupakan data hasil pengelompokan dari ekstraksi dokumen rancangan yang diperlukan untuk pemeriksaan ketidaksesuaian. Data ini tidak disimpan, hanya diproses. Informasi ini merupakan bagian dari triplet. Informasi ini merupakan bagian dari triplet.

Bukan

Bukan

Bukan

Informasi ini merupakan bagian dari triplet.


Kandidat

Pengertian

Kelas?

Penjelasan

22

Nama control class Pengelompokan hasil ekstraksi

Nama control class pada lifeline diagram urutan. Proses mengelompokkan pasangan kalimat alur kejadian dasar dengan triplet berdasarkan kasus penggunaannya. Proses menghitung kemiripan semantik antar kalimat dengan menggunakan metode tertentu.

Bukan

Informasi ini merupakan bagian dari triplet. Pengelompokan ini merupakan bagian dari pemeriksaan ketidaksesuaian.

Proses mendapatkan part-ofspeech suatu kata dari sebuah kalimat. Kelas suatu kata dalam sebuah kalimat. Misal, kata benda bentuk tunggal.

Bukan

23

24

Perhitungan kemiripan semantik kalimat

25

Tagging

26

part-ofspeech (POS)

Bukan

Ya

Bukan

Ada banyak metode perhitungan kemiripan sematik kalimat sehingga memungkinkan lebih dari satu implementasi metode tersebut. Proses ini merupakan bagian dari perhitungan kemiripan semantik kalimat. Kelas kata dalam bentuk penanda ini merupakan hasil dari tagging.


Kandidat

Pengertian

Kelas?

27

Perhitungan kemiripan semantik kata

Proses menghitung kemiripan semantik antar kata dengan menggunakan metode tertentu.

Ya

28

WordNet

Sebuah basis data leksikal bahasa Inggris.

Ya

29

Skor kemiripan

Nilai hasil perhitungan kemiripan semantik kalimat.

Bukan

30

Ambang batas

Tingkatan batas yang masih dapat diterima.

Bukan

Penjelasan Ada banyak metode perhitungan kemiripan semantik kata sehingga memungkinkan lebih dari satu implementasi metode tersebut. WordNet menyimpan kata benda, kata kerja, kata sifat, dan kata keterangan dalam sebuah kumpulan cognitive synonyms yang disebut dengan synsets. Data ini disimpan dalam bentuk file. Nilai ini digunakan untuk menentukan ambang batas (threshold) kemiripan semantik antara dua kalimat. Ambang batas sebagai nilai penentu kemiripan semantik antara dua kalimat.


Kandidat

Pengertian

Kelas?

Penjelasan

31

Label “Sesuai”

Label yang diberikan jika pasangan kalimat alur kejadian dasar dan triplet memenuhi ambang batas.

Bukan

32

Label “Tidak sesuai”

Label yang diberikan jika pasangan kalimat alur kejadian dasar dan triplet tidak memenuhi ambang batas.

Bukan

33

Hasil pemeriksaan ketidaksesuaian

Informasi hasil pemeriksaan ketidaksesuaian dokumen rancangan yang ditampilkan pada layar utama kakas bantu.

Ya

34

Nama kasus penggunaan

Nama dari suatu kasus penggunaan (use case).

Bukan

Label ini merupakan informasi yang nantinya diperlukan untuk menentukan penanda kesesuaian. Label ini merupakan bagian dari hasil pemeriksaan ketidaksesuaian. Label ini merupakan data yang nantinya akan diperlukan untuk menentukan penanda kesesuaian. Label ini merupakan bagian dari hasil pemeriksaan ketidaksesuaian. Hasil ini menyimpan informasi selama pemeriksaan ketidaksesuaian. Informasi tersebut terdiri dari nama kasus penggunaan, daftar kalimat alur kejadian dasar kasus penggunaan, dan daftar triplet dengan penanda kesesuaian. Nama kasus penggunaan merupakan bagian dari hasil pemeriksaan ketidaksesuaian.


Kandidat

Pengertian

Kelas?

Penjelasan

35

Daftar kalimat alur kejadian dasar kasus penggunaan Daftar triplet

Daftar kalimat alur kejadian dasar pada deskripsi kasus penggunaan yang telah dideteksi ketidaksesuaiannya. Daftar triplet yang telah dideteksi ketidaksesuaiannya. Penanda yang ditentukan dari label “Sesuai” dan “Tidak sesuai”. Penanda kesesuaian dibedakan dengan warna.

Bukan

Daftar ini merupakan bagian dari hasil pemeriksaan ketidaksesuaian.

Bukan

Daftar ini merupakan bagian dari hasil pemeriksaan ketidaksesuaian. Penanda ini merupakan bagian dari daftar kalimat alur kejadian dasar kasus penggunaan dan daftar triplet.

36

37

Penanda kesesuaian

Bukan

2.2. Membagi perilaku kasus penggunaan (use case) ke kelas analisis Kandidat-kandidat kelas yang telah terpilih kemudian dijabarkan ke dalam tiga stereotype kelas. Stereotype tersebut, antara lain kelas boundary, kelas control, dan kelas entity. Kelas boundary merupakan kelas yang menghubungkan antara entitas di luar sistem dengan sistem. Dengan kata lain, kelas ini berupa form, window sistem, atau interface untuk sistem lain. Entitas lain di luar sistem bisa berupa aktor atau sistem lain. Kelas control adalah kelas yang mengendalikan aliran logika sebuah kasus penggunaan (use case) dan mengoordinasikan objek lain. Kelas entity adalah kelas yang menyimpan informasi atau data yang digunakan oleh

66 sistem dalam jangka waktu yang lama. Biasanya, informasi tersebut disimpan ke dalam database atau file. Pemetaan kandidat kelas yang terpilih ke dalam nama kelas dan jenis kelas pada kakas bantu dijelaskan secara detail oleh Tabel 3.4.

Tabel 3.5 Pemetaan kandidat kelas kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” Kandidat

Nama

Deskripsi


MainGui

Jendela “Masukan berkas dokumen rancangan”

FileChooserDialog

Merepresentasikan objek antarmuka utama dari kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). Merepresentasikan objek antarmuka untuk memasukkan dokumen rancangan yang akan diperiksa ke dalam kakas bantu. Merepresentasikan objek yang mengatur komunikasi dari atau ke antarmuka utama kakas bantu. Merepresentasikan objek yang mengatur komunikasi antara antarmuka utama dengan antarmuka dialog.

–

MainGuiController

–

DialogHandler

Jenis

67 Tabel 3.5 Pemetaan kandidat kelas kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” (lanjutan) Kandidat –

Nama

Deskripsi

FileHandler

Merepresentasikan objek yang mengatur berkas yang dimasukkan (input file) atau disimpan (output file) pada kakas bantu. Merepresentasikan objek yang mengatur pemeriksaan ketidaksesuaian dokumen rancangan. Merepresentasikan objek yang menghitung kemiripan semantik antara dua kalimat dengan metode tertentu. Merepresentasikan objek yang menghitung kemiripan semantik antara dua kata dengan metode tertentu. Merepresentasikan objek yang menyimpan kata leksikal bahasa Inggris dalam kumpulan cognitive synonyms (synsets).


UcdSdInconsistencyDetector

Perhitungan kemiripan semantik kalimat

SentenceSimilarityScorer

Perhitungan kemiripan semantik kata

WordSimilarityScorer

WordNet

WordNet

Jenis

68 Tabel 3.5 Pemetaan kandidat kelas kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” (lanjutan) Kandidat

Nama

Deskripsi


UcdSdDetectionResult

Merepresentasikan objek yang menyimpan hasil pemeriksaan ketidaksesuaian dokumen rancangan selama pemeriksaan ketidaksesuaian.

Jenis

3. Untuk setiap hasil kelas analisis: 3.1. Mendeskripsikan tanggung jawab kelas Hasil kelas analisis yang telah dipetakan sebelumnya kemudian dideskripsikan tanggung jawabnya. Tanggung jawab kelas mendeskripsikan apa yang dilakukan oleh objek tersebut untuk memenuhi tanggung jawabnya. Dari tanggung jawab yang dilakukan, hasil apa yang didapatkan oleh objek tersebut. Tanggung jawab kelas dapat diidentifikasi melalui kata kerja yang ada pada alur kasus penggunaan (use case). Hasil identifikasi tersebut selanjutnya dipetakan ke dalam method-method. Hasil identifikasi kata kerja yang sudah dipetakan ke dalam method untuk setiap hasil kelas analisis dijabarkan oleh Tabel 3.6.

69 Tabel 3.6 Tanggung jawab kelas pada kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” Nama MainGui

FileChooserDialog

MainGuiController

DialogHandler

Notasi

Tanggung Jawab Mengirimkan perintah untuk menampilkan jendela “Masukan berkas dokumen rancangan” (clickMasukanBerkasButton) dan untuk melakukan pemeriksaan ketidaksesuaian dokumen rancangan (clickLakukanDeteksiButton). Mengirimkan penanda jika sebuah berkas dokumen rancangan telah dipilih (chooseFile) dan mengirimkan perintah untuk memasukkan berkas yang dipilih tersebut ke dalam kakas bantu (clickOpenButton). Menampilkan jendela “Masukan berkas dokumen rancangan” (showFileChooserDialog) dan mengirimkan perintah untuk melakukan pemeriksaan ketidaksesuaian (doInconsistencyDetection). Menampilkan jendela “Masukan berkas dokumen rancangan” (showFileChooserDialog) dan lokasi berkas dokumen rancangan yang dimasukkan ke dalam kakas bantu (showFilePath).

70 Tabel 3.6 Tanggung jawab kelas pada kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” (lanjutan) Nama FileHandler


Notasi

Tanggung Jawab Mengambil berkas dokumen rancangan yang dimasukkan ke dalam kakas bantu (getFile), mengecek format berkas dokumen rancangan (checkFileFormat), dan mengambil lokasi berkas dokumen rancangan (getFilePath). Melakukan ekstraksi berkas dokumen rancangan (extractDesignFile), mengambil kalimat alur kejadian dasar (basic flow) pada deskripsi kasus penggunaan (getUseCaseFlow), mengelompokkan kalimat alur kejadian dasar berdasarkan use case (groupUcfByUseCase), mengambil elemen diagram urutan (sequence diagram) (getSequenceDiagram), mengelompokkan elemen diagram urutan berdasarkan triplet (groupSdByTriplet), menghitung kesesuaian pasangan kalimat alur kejadian dasar dan triplet (calculateUcfTriplet), dan menyimpan setiap hasil deteksi ketidaksesuaian (setDetectionResult).

71 Tabel 3.6 Tanggung jawab kelas pada kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” (lanjutan) Nama

Notasi

Tanggung Jawab


Menghitung kemiripan antara dua kalimat dengan pendekatan/metode tertentu (similarity).


Menghitung kemiripan antara dua kata dengan pendekatan/metode tertentu (similarity).

WordNet

Mendapatkan kumpulan cognitive synonyms dari suatu kata (getSynsets).


Menyimpan hasil deteksi ketidaksesuaian (UcdSdDetectionResult).

3.2. Mendeskripsikan atribut dan hubungan kelas Kelas-kelas yang telah dijelaskan tanggung jawabnya melalui method kemudian dijabarkan kembali untuk mendeskripsikan atribut dan hubungannya dengan kelas lain. Atribut kelas digunakan untuk menyimpan data atau informasi dari sebuah kelas, sedangkan hubungan kelas menunjukkan komunikasi antara kelas-kelas yang memiliki tujuan untuk menjalankan kasus penggunaan (use case). Komunikasi terjadi saat suatu kelas mengirimkan atau menerima method dari kelas lain. Penjabaran dari atribut dan hubungan kelas ditunjukkan oleh Tabel 3.7.

72 Tabel 3.7 Atribut dan hubungan kelas pada kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” Nama

Atribut

Hubungan

MainGui

Kolom menampilkan file path dokumen rancangan, tombol “Masukan berkas...”, tombol “Lakukan deteksi”, dan area untuk menampilkan hasil deteksi ketidaksesuaian. Tombol “New Folder”, tombol “Delete File”, tombol “Rename File”, daftar folder, daftar file, kolom “Selection”, kolom “Filter”, tombol “Cancel”, dan tombol “Open”. –

MainGuiController

FileChooserDialog

MainGuiController DialogHandler FileHandler

–


–

SentenceSimilarityScorer WordSimilarityScorer UcdSdDetectionResult

–

–

– Elemen diagram yang telah diperiksa (kalimat alur kejadian dasar (basic flow) kasus penggunaan dan triplet) beserta label kesesuaian.

MainGuiController dan DialogHandler

DialogHandler dan UcdSdInconsistencyDetector FileHandler UcdSdConsistencyDetector UcdSdDetectionResult dan SentenceSimilarityScorer WordSimilarityScorer WordNet –

73 Tabel 3.7 Atribut dan hubungan kelas pada kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” (lanjutan) Nama

Atribut

WordNet

Kelompok kata benda, kata sifat, kata kerja, dan kata keterangan (synsets).

Hubungan –

3.1.9.2 Kelas Analisis Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian Kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” merupakan ekstensi atau perluasan dari kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”. Saat analis sistem telah memasukkan dokumen rancangan, analis sistem memiliki pilihan untuk mengekspor hasil pemeriksaan ketidaksesuaian ke bentuk laporan. Analisis kasus penggunaan ini dilakukan melalui langkahlangkah sebagai berikut: 1. Melengkapi penjelasan kasus penggunaan (use case) Kasus penggunaan ini dimulai saat analis sistem telah memasukkan dokumen rancangan ke dalam kakas bantu. Analis sistem memiliki dua pilihan apakah ingin mengekspor hasil pemeriksaan ketidaksesuaian ke bentuk laporan atau tidak. Jika iya, analis sistem mencentang opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” pada layar utama kakas bantu. Setelah opsi ini dicentang, analis sistem menekan tombol “Simpan hasil...”. Layar utama kakas bantu mengirimkan perintah untuk menampilkan jendela “Simpan hasil”. Jendela “Simpan hasil” berfungsi untuk memilih lokasi di mana laporan hasil pemeriksaan ketidaksesuaian akan disimpan. Analis sistem memilih lokasi penyimpanan terlebih dahulu pada jendela tersebut. Apabila lokasi sudah ditentukan, analis sistem memasukkan nama berkas laporan pada kolom masukan nama berkas dan memilih format berkas laporan (format “.doc”, “.docx”, atau “.pdf”) pada pilihan format berkas. Analis sistem menekan tombol “Save”. Kakas bantu kemudian mengambil lokasi di mana laporan hasil pemeriksaan ketidaksesuaian akan disim-

74 pan (file path). File path tersebut berisi informasi lokasi, nama, dan format berkas. Saat analis sistem menekan tombol “Save”, layar utama kakas bantu juga mengubah informasi bahwa nilai apakah hasil pemeriksaan ketidaksesuaian ke dalam laporan menjadi true. Nilai tersebut secara default adalah false. Selanjutnya, kakas bantu menampilkan lokasi hasil pemeriksaan ketidaksesuaian yang akan disimpan tadi pada kolom simpan hasil. Jika tidak ingin dieskpor ke bentuk laporan, analis sistem menekan tombol “Lakukan deteksi” untuk melakukan pemeriksaan ketidaksesuaian. Saat pemeriksaan ketidaksesuaian akan menampilkan hasil pemeriksaan, pemeriksaan ketidaksesuaian mengecek apakah hasil pemeriksaan ketidaksesuaian ke dalam laporan bernilai true. Jika iya, pemeriksaan ketidaksesuaian mengirim perintah untuk mengekspor hasil pemeriksaan ke bentuk laporan. Laporan yang dihasilkan berupa berkas dokumen yang berisi daftar kalimat alur kejadian dasar (basic flow) pada deskripsi kasus penggunaan (use case description) dan triplet dengan penanda kesesuaian (ditentukan berdasarkan label “Sesuai” dan “Tidak sesuai” yang dihasilkan selama pemeriksaan ketidaksesuaian). Laporan diekspor sesuai dengan nama, format, dan lokasi penyimpanan yang telah ditentukan sebelumnya pada jendela “Simpan hasil”. 2. Untuk setiap realisasi kasus penggunaan (use case): 2.1. Menemukan kandidat kelas dari perilaku kasus penggunaan (use case) Alur kasus penggunaan yang telah dilengkapi penjelasannya kemudian dianalisis perilakunya untuk mendapatkan kelas. Pendekatan yang dilakukan sama dengan pendekatan yang digunakan pada kasus penggunaan sebelumnya. Kandidat kelas bisa ditemukan melalui pemilihan kata benda pada alur kasus penggunaan. Tabel 3.8 menunjukkan kandidat kelas hasil analisis melalui pendekatan kata benda.

75 Tabel 3.8 Kandidat kelas kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” No.

Kandidat

Pengertian

Kelas?

Penjelasan

1

Analis sistem

Bukan

Analis sistem merupakan pengguna dari kakas bantu ini. Data analis sistem yang menggunakan kakas bantu tidak diproses di dalam sistem.

2

Opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” Layar utama kakas bantu

Peran yang memiliki tanggung jawab untuk menjembatani pengguna dan pengembang dalam sebuah proyek perangkat lunak. Opsi berupa kotak centang yang menandakan analis sistem mengekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan. Antarmuka utama kakas bantu yang menghubungkan analis sistem dengan kakas bantu (tempat proses bisnis berlangsung).

Bukan

Opsi ini merupakan salah satu komponen penyusun (atribut) layar utama kakas bantu.

Ya

Layar kakas bantu terdiri dari komponenkomponen seperti, opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan”, tombol “Simpan hasil...”, dan kolom simpan hasil.

3

76 Tabel 3.8 Kandidat kelas kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” (lanjutan) No.

Kandidat

Pengertian

Kelas?

Penjelasan

4

Tombol “Simpan hasil...”

Bukan


5

Jendela “Simpan hasil”

Tombol yang digunakan untuk memilih lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan. Jendela untuk memilih lokasi penyimpanan, memberikan nama, dan format laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan.

Ya

Jendela ini merupakan antarmuka yang menangani pemilihan lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian. Antarmuka ini terdiri dari komponen, seperti kolom memasukkan nama berkas laporan, pilihan untuk memilih format berkas laporan, dan tombol “Save”.


Kandidat

Pengertian

Kelas?

Penjelasan

6

Lokasi penyimpanan hasil pemeriksaan ketidaksesuaian

Lokasi yang berisi alamat dan format laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan yang akan disimpan (file path).

Bukan

7

Nama berkas laporan

Nama berkas laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan.

Bukan

8

Kolom masukan nama berkas

Kolom yang digunakan untuk memberikan nama berkas laporan yang akan disimpan.

Bukan

Lokasi penyimpanan merupakan informasi yang diperlukan untuk menentukan lokasi berkas laporan disimpan saat mengekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan. Nama berkas laporan merupakan informasi yang diperlukan untuk memberikan nama berkas laporan saat ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan. Kolom ini merupakan salah satu komponen penyusun (atribut) dari jendela “Simpan hasil”.


Kandidat

Pengertian

Kelas?

Penjelasan

9

Format berkas laporan

Bukan

Format berkas laporan merupakan informasi yang diperlukan untuk menentukan format berkas saat melakukan ekspor hasil pemeriksaaan ketidaksesuaian ke dalam laporan.

10

Pilihan format berkas

Bukan

Pilihan ini merupakan salah satu komponen penyusun (atribut) dari jendela “Simpan hasil”.

11

Tombol “Save”.

Format berkas laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan. Ada tiga format berkas laporan, yaitu “.doc’, “.docx”, dan “.pdf”. Pilihan yang digunakan untuk memilih jenis format laporan yang akan disimpan. Ada tiga format, yaitu “.doc”, “.docx”, dan “.pdf”. Tombol yang digunakan untuk menyimpan lokasi di mana laporan hasil pemeriksaan ketidaksesuaian nanti disimpan.

Bukan

Tombol ini merupakan salah satu komponen penyusun (atribut) dari jendela “Simpan hasil”.


Kandidat

Pengertian

Kelas?

Penjelasan

12

Nilai apakah hasil pemeriksaan ketidaksesuaian ke dalam laporan

Bukan

Nilai ini merupakan informasi yang menentukan apakah hasil pemeriksaan ketidaksesuaian dieskpor ke dalam laporan.

13

Kolom simpan hasil

Bukan

Kolom ini merupakan salah satu komponen penyusun (atribut) layar utama kakas bantu.

14

Tombol “Lakukan deteksi”

Nilai yang menandakan apakah hasil pemeriksaan ketidaksesuaian akan diekspor ke dalam laporan atau tidak. Nilai ini bernilai true atau false. Kolom ini menampilkan lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian (file path). Tombol yang digunakan untuk melakukan pemeriksaan ketidaksesuaian dokumen rancangan yang telah dimasukkan ke kakas bantu.

Bukan



Kandidat

Pengertian

15


16


Proses untuk memeriksa ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). Informasi hasil pemeriksaan ketidaksesuaian dokumen rancangan yang ditampilkan pada layar utama kakas bantu.

Kelas? Ya

Ya

Penjelasan Pemeriksaan ketidaksesuaian mengatur deteksi ketidaksesuaian mulai dari ekstraksi dokumen rancangan hingga menampilkan hasil pemeriksaan ketidaksesuaian. Hasil ini menyimpan informasi selama pemeriksaan ketidaksesuaian. Informasi tersebut terdiri dari nama kasus penggunaan, daftar kalimat alur kejadian dasar kasus penggunaan, dan daftar triplet dengan penanda kesesuaian. Nantinya, informasi ini diperlukan saat ditampilkan di layar utama kakas bantu atau diekspor ke bentuk laporan.


Kandidat

Pengertian

Kelas?

Penjelasan

17

Laporan

Bukan

Berkas laporan merupakan hasil keluaran (output) dari pemilihan opsi ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan.

18

Daftar kalimat alur kejadian dasar (basic flow)

Bukan

Daftar ini merupakan bagian dari hasil pemeriksaan ketidaksesuaian.

19

Daftar triplet

Bukan

20

Penanda kesesuaian

Berkas laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan yang disimpan pada lokasi yang telah ditentukan. Daftar kalimat alur kejadian dasar pada deskripsi kasus penggunaan yang telah dideteksi ketidaksesuainnya. Daftar triplet yang telah dideteksi ketidaksesuaiannya. Penanda yang ditentukan dari label “Sesuai” dan “Tidak sesuai”. Penanda kesesuaian dibedakan dengan warna.

Daftar ini merupakan bagian dari hasil pemeriksaan ketidaksesuaian. Penanda ini merupakan bagian dari daftar kalimat alur kejadian dasar kasus penggunaan dan daftar triplet.

Bukan

2.2. Membagi perilaku kasus penggunaan (use case) ke kelas analisis Kandidat-kandidat kelas yang telah terpilih kemudian dijabarkan

82 ke dalam tiga stereotype kelas. Stereotype tersebut antara lain kelas boundary, kelas control, dan kelas entity. Tidak jauh berbeda dengan penjelasan kelas analisis kasus penggunaan sebelumnya, kelas boundary merupakan kelas yang menghubungkan antara entitas di luar sistem dengan sistem. Dengan kata lain, kelas ini berupa form, window sistem, atau interface untuk sistem lain. Kelas control adalah kelas yang mengendalikan aliran logika sebuah kasus penggunaan dan mengoordinasikan objek lain. Kelas entity adalah kelas yang menyimpan informasi atau data yang digunakan oleh sistem dalam jangka waktu yang lama. Pemetaan kandidat kelas yang terpilih ke dalam nama kelas dan jenis kelas pada kakas bantu dijelaskan secara detail oleh Tabel 3.8.

Tabel 3.9 Pemetaan kandidat kelas kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” Kandidat

Nama

Deskripsi


MainGui

Jendela “Simpan hasil”

SaveReportDialog

Merepresentasikan objek antarmuka utama dari kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). Merepresentasikan objek antarmuka untuk memilih lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan.

Jenis

83 Tabel 3.9 Pemetaan kandidat kelas kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” (lanjutan) Kandidat

Nama

Deskripsi

–

MainGuiController

–

DialogHandler

–

FileHandler

Merepresentasikan objek yang mengatur komunikasi dari atau ke antarmuka utama kakas bantu. Merepresentasikan objek yang mengatur komunikasi antara antarmuka utama dengan antarmuka dialog. Merepresentasikan objek yang mengatur berkas yang dimasukkan (input file) atau disimpan (output file) pada kakas bantu. Merepresentasikan objek yang mengatur pemeriksaan ketidaksesuaian dokumen rancangan. Merepresentasikan objek yang mengatur ekspor hasil pemeriksaan ketidaksesuaian dokumen rancangan ke bentuk laporan.


–


ReportHandler

Jenis

84 Tabel 3.9 Pemetaan kandidat kelas kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” (lanjutan) Kandidat –


Nama

Deskripsi

DocumentWriter

Merepresentasikan objek yang mengekspor hasil pemeriksaan ketidaksesuaian dokumen rancangan ke bentuk laporan. Merepresentasikan objek yang menyimpan hasil pemeriksaan ketidaksesuaian dokumen rancangan selama pemeriksaan ketidaksesuaian.


Jenis

3. Untuk setiap hasil kelas analisis: 3.1. Mendeskripsikan tanggung jawab kelas Tidak jauh berbeda dengan penjelasan kelas analisis kasus penggunaan sebelumnya, hasil kelas analisis yang telah dipetakan sebelumnya kemudian dideskripsikan tanggung jawabnya. Tanggung jawab kelas mendeskripsikan apa yang dilakukan oleh objek tersebut untuk memenuhi tanggung jawabnya. Dari tanggung jawab yang dilakukan, hasil apa yang didapatkan oleh objek tersebut. Tanggung jawab kelas dapat diidentifikasi melalui kata kerja yang ada pada alur kasus penggunaan (use case). Hasil identifikasi tersebut selanjutnya dipetakan ke dalam method-method. Hasil identifikasi kata kerja yang sudah dipetakan ke dalam method untuk setiap hasil kelas analisis dijabarkan oleh Tabel 3.10.

85 Tabel 3.10 Tanggung jawab kelas pada kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” Nama MainGui

SaveReportDialog

MainGuiController

DialogHandler

Notasi

Tanggung Jawab Mencentang opsi untuk mengekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan (checkExportToReportOption) dan mengirimkan perintah untuk menampilkan jendela “Simpan hasil” (clickSimpanHasilButton). Memilih lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian (chooseSavedReportLocation), memilih format laporan hasil pemeriksaaan ketidaksesuaian (chooseSavedReportFormat), memasukkan nama berkas laporan hasil pemeriksaan ketidaksesuaian (inputSavedReportFileName), dan menyimpan lokasi penyimpanan berkas laporan (clickSaveButton). Menampilkan jendela “Simpan hasil” (showSaveReportDialog).

Menampilkan jendela “Simpan hasil” (showSaveReportDialog) dan lokasi penyimpanan berkas laporan (showFilePath).

86 Tabel 3.10 Tanggung jawab kelas pada kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” (lanjutan) Nama

Notasi

Tanggung Jawab

FileHandler

Mengambil berkas laporan (getFile) dan lokasi berkas laporan (getFilePath).


Melakukan ekstraksi berkas dokumen rancangan (extractDesignFile), mengambil kalimat alur kejadian dasar (basic flow) pada deskripsi kasus penggunaan (getUseCaseFlow), mengelompokkan kalimat alur kejadian dasar berdasarkan use case (groupUcfByUseCase), mengambil elemen diagram urutan (sequence diagram) (getSequenceDiagram), mengelompokkan elemen diagram urutan berdasarkan triplet (groupSdByTriplet), menghitung kesesuaian pasangan kalimat alur kejadian dasar dan triplet (calculateUcfTriplet), dan menyimpan setiap hasil deteksi ketidaksesuaian (setDetectionResult). Mengatur ekspor hasil deteksi ketidaksesuaian ke bentuk laporan dengan mengubah informasi ekspor hasil ke laporan menjadi true (ReportHandler).

ReportHandler

87 Tabel 3.10 Tanggung jawab kelas pada kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” (lanjutan) Nama

Notasi

Tanggung Jawab

DocumentWriter

Mengekspor hasil deteksi ketidaksesuaian ke dalam bentuk laporan (writeToDocument).


Menyimpan hasil deteksi ketidaksesuaian dengan menyimpan objek UseCaseDescriptionDetectionResult dan TripletDetectionResult (UcdSdDetectionResult).

3.2. Mendeskripsikan atribut dan hubungan kelas Kelas-kelas yang telah dijelaskan tanggung jawabnya melalui method dijabarkan kembali ke dalam atribut dan hubungannya dengan kelas lain. Atribut digunakan untuk menyimpan data atau informasi dari sebuah kelas, sedangkan hubungan kelas menunjukkan komunikasi antara kelas-kelas yang memiliki tujuan untuk menjalankan kasus penggunaan (use case). Komunikasi terjadi saat suatu kelas mengirim atau menerima method dari kelas lain. Penjabaran dari atribut dan hubungan kelas ditunjukkan oleh Tabel 3.11.

Tabel 3.11 Atribut dan hubungan kelas pada kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” Nama

Atribut

Hubungan

MainGui

Opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan”, tombol “Simpan hasil...”, tombol “Lakukan deteksi”, dan kolom simpan hasil.

MainGuiController

88 Tabel 3.11 Atribut dan hubungan kelas pada kasus penggunaan (use case) “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” Nama

Atribut

Hubungan

SaveReportDialog

Kolom memasukkan nama berkas, pilihan jenis format berkas, dan tombol “Save”. –

DialogHandler

MainGuiController DialogHandler FileHandler UcdSdInconsistencyDetector ReportHandler DocumentWriter UcdSdDetectionResult

3.1.10

– – –

–

DialogHandler FileHandler dan ReportHandler – UcdSdDetectionResult dan ReportHandler DocumentWriter

–

–

Elemen diagram yang telah diperiksa (kalimat alur kejadian dasar (basic flow) kasus penggunaan dan triplet) beserta label kesesuaian.

–

Diagram Urutan (Sequence Diagram)

Dari analisis yang telah dilakukan pada subbab sebelumnya, kelaskelas yang telah didapatkan memiliki hubungan satu sama lain yang berinteraksi melalui serangkaian method. Bentuk interaksi tersebut digambarkan dalam sebuah diagram, yaitu diagram urutan. Diagram urutan adalah diagram yang merealisasikan sebuah kasus penggunaan (use case) melalui interaksi serangkaian objek-objek. Karena terdapat Ada dua kasus penggunaan yang telah dianalisis perilakunya, yaitu memeriksa ketidaksesuaian dokumen rancangan dan mengekspor laporan hasil pemeriksaan ketidaksesuaian. Sehingga, masing-masing kasus penggunaan memiliki

89 diagram urutan. Diagram urutan tersebut sebagai berikut: 1. Diagram urutan dari kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan”. Diagram urutan dari kasus penggunaan ini ditunjukkan oleh Gambar 3.5. Kelas-kelas yang terlibat dalam interaksi sesuai dengan hasil analisis kelas sebelumnya. Bentuk komunikasi antar kelas melalui method.

Gambar 3.5 Diagram urutan (sequence diagram) kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” Diagram urutan kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” mengandung referensi diagram urutan lain. Di-

90 agram urutan tersebut, antara lain diagram urutan kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” dan diagram urutan proses mendeteksi ketidaksesuaian. Diagram urutan kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” menjelaskan titik ekstensi dari kasus penggunaan ini, sedangkan diagram urutan proses mendeteksi ketidaksesuaian menjelaskan proses deteksi ketidaksesuain yang ada di dalam kasus penggunaan ini. Diagram tersebut ditunjukkan oleh Gambar 3.6.

Gambar 3.6 Diagram urutan (sequence diagram) proses mendeteksi ketidaksesuaian

91 2. Diagram urutan dari kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian”. Diagram urutan dari kasus penggunaan ini ditunjukkan oleh Gambar 3.7. Sesuai gambar tersebut, kelas-kelas yang terlibat juga merupakan hasil dari analisis kelas sebelumnya.

Gambar 3.7 Diagram urutan (sequence diagram) kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian”

Pada kasus penggunaan sebelumnya, diagram urutan proses mendeteksi ketidaksesuaian merujuk diagram urutan “Mengeskpor Hasil Deteksi ke Laporan”. Diagram tersebut menjelaskan proses pengolahan hasil deteksi ketidaksesuaian menjadi bentuk laporan. Proses ini dilakukan apabila hasil deteksi ketidaksesuaian diekspor ke bentuk laporan. Diagram dari proses ini ditunjukkan oleh Gambar 3.8.

92

Gambar 3.8 Diagram urutan (sequence diagram) proses mengekspor hasil deteksi ke laporan

3.2

Perancangan Perangkat Lunak

Bab ini akan dibahas perancangan perangkat lunak dari Tugas Akhir yang berjudul “Pembuatan Kakas Bantu untuk Mendeteksi Ketidaksesuaian Diagram Urutan (Sequence Diagram) dengan Diagram Kasus Penggunaan (Use Case Diagram)”.

3.2.1

Perancangan Antarmuka

Subbab ini membahas spesifikasi rancangan antarmuka dari kakas bantu. Spesifikasi rancangan antarmuka meliputi deskripsi atribut apa saja yang ada pada rancangan antarmuka dan desain antarmuka. Kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram) memiliki dua antarmuka. Antarmuka tersebut secara detail dijelaskan pada bahasan berikut ini.

3.2.1.1

Antarmuka Utama

Antarmuka utama adalah layar yang muncul pertama kali ketika analis sistem membuka kakas bantu ini. Antarmuka utama terdiri dari komponen-komponen yang mendukung kebutuhan utama analis sistem. Komponen tersebut, antara lain komponen untuk memasukkan dokumen

93 rancangan dan menampilkan hasil pemeriksaan ketidaksesuaian dokumen rancangan. Penjelasan masing-masing komponen dijelaskan pada Tabel 3.12.

Tabel 3.12 Spesifikasi atribut antarmuka utama kakas bantu No.

Nama

Jenis

Kegunaan

Tipe Data

1

Alamat berkas dokumen rancangan

Text Field

String

2

Masukan berkas

Button

3

Lakukan deteksi

Button

4

Area menampilkan hasil pemeriksaan ketidaksesuaian dokumen rancangan

Text Pane

Tempat untuk menampilkan lokasi berkas dokumen rancangan yang akan diperiksa oleh kakas bantu. Tombol untuk memasukkan berkas dokumen rancangan yang akan diperiksa ke dalam kakas bantu. Tombol untuk memulai deteksi ketidaksesuaian dokumen rancangan yang telah dimasukkan ke dalam kakas bantu Tempat untuk menampilkan hasil pemeriksaan ketidaksesuaian rancangan. Informasi yang ditampilkan, antara lain nama kasus penggunaan (use case), kalimat alur kejadian dasar (basic flow) kasus penggunaan, triplet, dan label kesesuaian.

–

–

List of string

3.2.1.2 Jendela Masukan Berkas Dokumen Rancangan Jendela masukan berkas dokumen rancangan adalah antarmuka berupa sebuah jendela yang merupakan bagian dari antarmuka utama kakas bantu (subwindow). Komponen jendela ini, seperti tombol “New Folder”, tombol “Delete File”, tombol “Rename File”, daftar folder, daftar file, ko-

94 lom “Filter”, tombol “Cancel”, dan tombol “Open”. Analis sistem memilih berkas dokumen rancangan pada lokasi penyimpanan tempat berkas tersebut disimpan. Ketika berkas dokumen rancangan dipilih, analis sistem harus menekan tombol ”Open” untuk memasukkan berkas ke dalam kakas bantu. Komponen-komponen dari jendela masukan berkas dijelaskan secara detail pada Tabel 3.13.

Tabel 3.13 Spesifikasi atribut jendela masukan berkas dokumen rancangan No.

Nama

Jenis

Kegunaan

1

New Folder

Button

2

Delete File

Button

3

Rename File

Button

4

Daftar folder

List

5

Daftar file

List

6

Selection

Text Field

7

Filter

Combo Box

8

Cancel

Button

Tombol untuk membuat folder baru pada daftar folder. Tombol untuk menghapus file yang terpilih pada daftar file. Tombol untuk mengubah nama file yang terpilih pada daftar file. Daftar untuk menampilkan folder yang ada di dalam sistem. Daftar untuk menampilkan file sesuai folder yang terpilih di dalam sistem. Kolom untuk menampilkan lokasi saat ini dan nama berkas dokumen rancangan yang dipilih. Kolom untuk menyaring jenis atau format file yang ditampilkan pada daftar file. Tombol untuk membatalkan perintah memasukkan berkas dokumen rancangan.

Tipe Data –

–

–

List of files List of files String

List of string –

95 Tabel 3.13 Spesifikasi atribut jendela masukan berkas dokumen rancangan (lanjutan) No. 9

Nama

Jenis

Kegunaan

OK

Button

Tombol untuk memasukkan berkas dokumen rancangan yang dipilih ke dalam kakas bantu.

Tipe Data –

3.2.1.3 Antarmuka Ekspor Hasil Pemeriksaan ke dalam Laporan Antarmuka ekspor hasil pemeriksaan ke dalam laporan adalah antarmuka tambahan yang digunakan analis sistem untuk memilih opsi ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan. Antarmuka ini merupakan bagian dari antarmuka utama kakas bantu. Komponen antarmuka ini berupa opsi dan tombol memasukkan lokasi penyimpanan laporan. Setelah analis sistem mencentang opsi ini, tombol memasukkan lokasi penyimpanan laporan akan aktif. Tombol memasukkan lokasi penyimpanan laporan secara default tidak aktif sebelum analis sistem mencentang opsi ekspor hasil pemeriksaan ke dalam laporan. Masing-masing komponen antarmuka kemudian dijelaskan pada Tabel 3.14.

Tabel 3.14 Spesifikasi atribut antarmuka ekspor hasil pemeriksaan ke dalam laporan No. 1

Nama

Jenis

Kegunaan

Tipe Data

Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan

Check Box

Tempat untuk memilih opsi ekspor hasil pemeriksaan ketidaksesuaian dokumen rancangan ke dalam laporan.

Boolean

96 Tabel 3.14 Spesifikasi atribut antarmuka ekspor hasil pemeriksaan ke dalam laporan (lanjutan) No.

Nama

Jenis

Kegunaan

Tipe Data

2

Alamat berkas laporan hasil pemeriksaan

Text Field

String

3

Simpan hasil

Button

Tempat untuk menampilkan lokasi di mana laporan hasil pemeriksaan ketidaksesuaian dokumen rancangan disimpan. Tombol untuk memilih lokasi penyimpanan, memasukkan nama, dan memilih format laporan hasil pemeriksaan ketidaksesuaian yang akan disimpan.

3.2.1.4

–

Jendela Simpan Hasil

Jendela simpan hasil adalah antarmuka berupa sebuah jendela yang merupakan bagian dari antarmuka utama kakas bantu (subwindow). Komponen jendela ini hampir sama dengan jendela masukan berkas dokumen rancangan. Analis sistem memilih lokasi penyimpanan laporan hasil deteksi ketidaksesuaian. Ketika lokasi sudah dipilih, analis sistem memasukkan nama laporan beserta memilih format berkas laporan hasil deteksi ketidaksesuaian dokumen rancangan. Analis sistem selanjutnya menekan tombol “Save” untuk menyimpan lokasi penyimpanan laporan. Penjelasan dari masing-masing komponen tersebut dijelaskan pada Tabel 3.15.

Tabel 3.15 Spesifikasi atribut jendela simpan hasil No. 1

Nama

Jenis

Kegunaan

New Folder

Button

Tombol untuk membuat folder baru pada daftar folder.

Tipe Data –

97 Tabel 3.15 Spesifikasi atribut jendela simpan hasil (lanjutan) No.

Nama

Jenis

Kegunaan

2

Delete File

Button

3

Rename File

Button

4

Daftar folder

List

5

Daftar file

List

6

Selection

Text Field

7

Filter

Combo Box

8

Cancel

Button

9

OK

Button

Tombol untuk menghapus file yang terpilih pada daftar file. Tombol untuk mengubah nama file yang terpilih pada daftar file. Daftar untuk menampilkan folder yang ada di dalam sistem. Daftar untuk menampilkan file sesuai folder yang terpilih di dalam sistem. Kolom untuk menampilkan lokasi saat ini dan memasukkan nama laporan hasil deteksi ketidaksesuaian. Kolom untuk memilih jenis atau format file laporan yang akan disimpan. Tombol untuk membatalkan perintah menyimpan laporan hasil deteksi ketidaksesuaian. Tombol untuk menyimpan lokasi dan nama laporan hasil deteksi ketidaksesuaian.

Tipe Data –

–

List of files List of files String

List of String –

–

3.2.2 Perancangan Proses Kakas Bantu Pendeteksian ketidaksesuaian dokumen rancangan merupakan proses yang terjadi di dalam kakas bantu yang hendak diimplementasikan. Implementasi tersebut membahas bagaimana alur dan metode untuk mendeteksi ketidaksesuaian antara diagram urutan (sequence diagram) dengan

98 diagram kasus penggunaan (use case diagram). Secara garis besar, kakas bantu ini memiliki tiga proses utama, yaitu mengekstraksi dokumen rancangan, mendeteksi ketidaksesuaian dokumen rancangan, dan menampilkan hasil pendeteksian. Proses utama tersebut digambarkan melalui arsitektur perangkat lunak pada Gambar 3.9.

Gambar 3.9 Arsitektur perangkat lunak Dari gambar arsitektur perangkat lunak, hubungan antara analis sistem dengan kakas bantu dapat dilihat. Analis sistem memasukkan dokumen rancangan untuk dideteksi ketidaksesuaiannya. Kemudian, kakas bantu melalui beberapa tahapan proses untuk melakukan deteksi ketidaksesuaian. Tahapan proses tersebut dijelaskan lebih detail pada subbab berikut ini.

3.2.2.1

Proses Membuat Dokumen Rancangan

Dokumen rancangan dibuat terlebih dahulu menggunakan aplikasi StarUML 2 [2]. Adapun struktur dokumen rancangan yang hendak dibuat pada aplikasi tersebut. Dokumen rancangan berisi sebuah proyek. Di dalam proyek tersebut, terdapat satu buah model yang terdiri dari diagram kasus penggunaan (use case diagram), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram). Sebuah proyek berisi identitas dari proyek tersebut, misal nama proyek, nama orang yang terlibat, nama perusahaan, dan versi proyek itu sendiri. Sedangkan model, model diibaratkan sebagai tempat untuk menampung berbagai jenis diagram UML. Ilustrasi dari struktur dokumen rancangan ditunjukkan

99 pada Gambar 3.10.

Gambar 3.10 Struktur proyek dokumen rancangan pada aplikasi StarUML 2 Dari gambar tersebut, proyek ditunjukkan dengan nama “Online Shopping Project”. Terdapat sebuah model dengan nama “Model” yang terdiri dari diagram kasus penggunaan dan diagram urutan. Diagram kasus penggunaan ditunjukkan dengan nama “Use Case Diagram”. Diagram tersebut terdiri dari batas sistem “Online Shopping System”, kasus penggunaan (use case) “Buy a Product”, dan aktor “Customer”. Diagram urutan ditunjukkan dengan nama “Buy a Product” (di bawah hierarki “Collaboration1”) sebagai realisasi kasus penggunaan “Buy a Product”. Elemen dari kedua diagram ini harus diletakkan secara berurutan pada hierarki proyek. Diagram kasus penggunaan yang dibuat harus mengandung elemen aktor, relasi, kasus penggunaan, dan batas antara aktor dengan sistem. Adapun contoh diagram kasus penggunaan yang mengandung elemen-elemen tersebut. Contoh diagram ditunjukkan oleh Gambar 3.11. Diagram tersebut memiliki sebuah kasus penggunaan yang bernama “Buy a Product”. Kasus penggunaan ini mempunyai sebuah deskripsi yang disebut deskripsi kasus penggunaan. Bagian yang dimasukkan ke dalam deskripsi kasus penggunaan hanya kalimat alur kejadian dasar (ba-

100

Gambar 3.11 Diagram kasus penggunaan (use case diagram) “Online Shopping System” sic flow). Kalimat tersebut berupa dialog antara aktor dan sistem. Gambar 3.12 menunjukkan kalimat alur kejadian dasar dari kasus penggunaan “Buy a Product”1 .

Gambar 3.12 Alur dasar (basic flow) kasus penggunaan “Buy a Product” Deskripsi kasus penggunaan (use case description) dari sebuah kasus penggunaan (use case) dimasukkan melalui area documentation pada sidebar editors aplikasi StarUML 2 (ditunjukkan oleh Gambar 2.3). Adapun aturan dari deskripsi kasus penggunaan yang hendak dimasukkan. Aturan tersebut dijelaskan sebagai berikut: 1

Alur kasus penggunaan (use case) diambil dari buku UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd edition, halaman 101.

101 1. Deskripsi dari sebuah kasus penggunaan berupa sebuah paragraf Deskripsi dari sebuah kasus penggunaan berisi kalimat alur kejadian dasar (basic flow). Alur tersebut berisi dialog antara aktor dan sistem. Aktor memulai dengan memberikan sebuah tindakan ke sistem kemudian sistem memberikan respon terhadap tindakan tersebut. Biasanya, alur tersebut diberikan nomor untuk mengetahui urutan kejadian. Jika alur kejadian berupa alur yang bernomor maka alur harus diubah ke dalam bentuk paragraf. Paragraf yang dihasilkan tetap memerhatikan urutan kejadian. Alur pertama menjadi kalimat pertama, alur kedua menjadi kalimat berikutnya, dan seterusnya. Misal, alur kejadian dasar kasus penggunaan “Buy a Product” menjadi sebuah paragraf deskripsi kasus penggunaan sebagai berikut: Customer browses catalog and selects item to buy. Customer goes to check out. Customer fills in shipping information (address; next-day or 3-day delivery). System presents full pricing information, including shipping. Customer fills in credit card information. System authorizes purchase. System confirms sale immediately. System sends confirming e-mail to customer. 2. Deskripsi dari sebuah kasus penggunaan berisi kalimat sederhana Kalimat alur kejadian dasar pada deskripsi kasus penggunaan harus berupa kalimat sederhana. Kalimat sederhana adalah kalimat yang terdiri dari satu aktor/pelaku dan satu tindakan/respon. Kalimat berikut merupakan contoh kalimat yang terdiri dari dua tindakan yang dilakukan oleh satu aktor: Customer browses catalog and selects items to buy. Kalimat tersebut harus dinormalisasi menjadi dua kalimat sederhana: Customer browses catalog. Customer selects items to buy. 3. Deskripsi dari sebuah kasus penggunaan menggunakan kalimat aktif Bentuk kalimat alur kejadian dasar kasus penggunaan berupa kalimat aktif. Jika kalimat tersebut berupa kalimat pasif maka kalimat harus diubah ke bentuk kalimat aktif. Kalimat berikut adalah contoh kalimat pasif: A save page dialog is displayed. Kalimat tersebut harus dinormalisasi menjadi kalimat aktif: The system displays a save page dialog. 4. Deskripsi dari sebuah kasus penggunaan mengubah kata ganti de-

102 ngan nama objek Kalimat alur kejadian dasar kasus penggunaan bisa mengandung kata ganti. Kata ganti tersebut harus diubah ke nama objek asli. Misal, kalimat yang mengandung kata ganti him: The ATM returns the card to him. Kalimat tersebut diubah dengan nama objek asli, misal menjadi: The ATM returns the card to the customer. 5. Deskripsi dari sebuah kasus penggunaan menghilangkan informasi tambahan tanpa mengubah substansi Kalimat alur kejadian dasar kasus penggunan bisa berupa kalimat kompleks yang mengandung informasi atau keterangan tambahan. Keterangan tambahan tersebut dihilangkan selama tidak mengubah substansi dari kalimat itu sendiri. Contoh kalimat alur kejadian yang mengadung keterangan tambahan sebagai berikut. The Add a Person use case is initiated when the user clicks the “Add” button in the main window. Kalimat tersebut disederhanakan menjadi kalimat: The user clicks the “Add” button in the main window. 6. Deskripsi dari sebuah kasus penggunaan berisi kalimat alur yang sukses Kalimat alur kejadian dasar penggunaan bisa mengandung alur yang menyebabkan tujuan aktor pada suatu kasus penggunaan tidak tercapai. Oleh sebab itu, deskripsi yang dimasukkan hanya berupa kalimat yang membuat suatu kasus penggunaan tercapai. Pemberian aturan pada deskripsi kasus penggunaan bertujuan untuk menghilangkan keambiguan suatu kalimat. Kalimat alur kejadian pada deskripsi kasus penggunaan pada dasarnya diawali dengan aktor yang aktif memicu sebuah tindakan ke sistem kemudian sistem memberikan respon terhadap tindakan tersebut. Selanjutnya, diagram urutan (sequence diagram) yang dibuat terdiri dari judul diagram, kelas aktor, kelas lain yang berinteraksi (boundary, controller, dan entity), dan pesan (message) berupa sebuah method. Contoh diagram urutan ditunjukkan oleh Gambar 3.13. Gambar tersebut adalah gambar yang sesuai dengan aturan. Aturan yang dimaksud adalah aturan dalam pembuatan diagram urutan. Aturan tersebut dijelaskan sebagai berikut: 1. Judul diagram urutan (sequence diagram) Judul diagram urutan adalah nama dari sebuah kasus penggunaan (use

103 case).

Gambar 3.13 Diagram urutan (sequence diagram) “Buy a Product” Nama kasus penggunaan tersebut harus berkorespondensi dengan diagram urutan yang dimaksud. Hal ini dilakukan untuk mengetahui diagram urutan mana yang merealisasikan skenario dari suatu kasus penggunaan. 2. Kelas (class) yang berinteraksi Kelas yang berinteraksi pada diagram urutan, antara lain kelas aktor, boundary, control, dan entity. Adapun format penulisan dari sebuah kelas, yaitu tanda titik dua ditambah nama kelas dalam upper camel case. Contoh nama kelas dengan format tersebut, seperti “: BrowseInterface”. Selain itu, kelas juga diberikan sebuah stereotype untuk membedakan jenis kelas tersebut. Terdapat empat stereotype kelas, yaitu actor, boundary, control, dan entity. Pemberian stereotype kelas sangat diperlukan untuk proses ekstraksi dokumen rancangan nantinya. 3. Pesan (message) yang dikirim atau diterima

104 Pesan berupa sebuah yang method yang dikirim atau diterima oleh sebuah kelas. Penulisan nama method ditulis dengan format lower camel case. Contoh, nama method dengan format penulisan tersebut, seperti “browseItems”. Setelah dokumen rancangan selesai dibuat, hasil dokumen rancangan kemudian diekspor ke dalam format “.xmi” menggunakan XMI extension dari StarUML 2. Proses ekspor melalui menu “File →Export →XMI Export...” pada aplikasi StarUML 2. Dokumen rancangan dalam format “.xmi” inilah yang nantinya dimasukkan ke dalam kakas bantu.

3.2.2.2

Proses Memasukkan Dokumen Rancangan

Memasukkan dokumen rancangan ke dalam kakas bantu merupakan proses pertama yang dilakukan oleh analis sistem sebelum melakukan deteksi ketidaksesuaian dokumen rancangan. Sesuai penjelasan sebelumnya, dokumen rancangan yang akan dideteksi berisi diagram kasus penggunaan (use case diagram), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram). Dokumen rancangan tersebut dalam format “.xmi”. Proses memasukkan berkas dimulai dengan menekan tombol “Masukan berkas...” pada antarmuka utama kakas bantu. Tombol ini akan menampilkan jendela “Masukan berkas dokumen rancangan”. Jendela tersebut digunakan untuk memilih lokasi di mana dokumen rancangan disimpan. Saat jendela “Masukan berkas dokumen rancangan” muncul, lokasi yang pertama kali ditampilkan adalah root directory dari file system analis sistem. Analis sistem mencari lokasi di mana dokumen rancangan disimpan dan memilih dokumen rancangan pada lokasi tersebut. Untuk memasukkan dokumen rancangan, analis sistem menekan tombol “Open” pada jendela “Masukan dokumen rancangan”. Dokumen rancangan yang telah dipilih akan dicek terlebih dahulu formatnya, apakah dalam format “.xmi” atau tidak. Jika iya, mengambil alamat dari berkas rancangan tersebut (file path) untuk ditampilkan pada kolom lokasi dokumen rancangan antarmuka utama kakas bantu. Jika tidak, memberikan sebuah pesan peringatan bahwa format dokumen rancangan yang dimasukkan tidak sesuai. Analis sistem diminta untuk memasukkan kembali dokumen rancangan yang sesuai dengan format yang telah ditentukan. Lokasi terakhir di mana analis sistem memilih dokumen rancangan disimpan. Tujuannya adalah memudahkan analis sistem untuk kembali ke lokasi tersebut tanpa harus memulai dari root directory ketika

105 salah memasukkan dokumen rancangan.

3.2.2.3 Proses Memilih Opsi Ekspor Hasil Deteksi Ketidaksesuaian Proses memasukkan dokumen rancangan ke dalam kakas bantu kemudian dilanjutkan dengan memilih opsi ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan. Opsi ini bersifat pilihan, yang berarti analis sistem dapat memilih ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan atau tidak. Apabila pengguna memilih opsi ini, hasil pemeriksaan ketidaksesuaian akan diekspor ke dalam sebuah laporan. Laporan tersebut berupa dokumen yang berisi hasil deteksi ketidaksesuaian dengan dilengkapi informasi bagian sesuai dan tidak sesuai dari dokumen rancangan. Laporan yang dihasilkan memiliki format “.doc”, “.docx”, atau “.pdf”. Analis sistem harus memilih salah satu dari dua jenis format laporan. Pemilihan opsi ini ditandai saat analis sistem mencentang opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” pada antarmuka utama kakas bantu. Ketika opsi tersebut dicentang, tombol “Simpan hasil...” akan aktif. Analis sistem menekan tombol tersebut dan antarmuka utama kakas bantu akan menampilkan jendela “Simpan hasil”. Jendela ini digunakan untuk memilih lokasi penyimpanan laporan hasil deteksi ketidaksesuaian. Saat jendela “Simpan hasil” muncul, lokasi yang pertama kali ditampilkan adalah root directory dari file system analis sistem. Analis sistem memilih lokasi laporan yang akan disimpan. Apabila lokasi penyimpanan telah ditentukan, analis sistem memasukkan nama laporan pada kolom memasukkan nama berkas jendela “Simpan hasil”. Analis sistem kemudian memilih format dokumen pada pilihan format berkas jendela “Simpan hasil”. Analis sistem menekan tombol “Save” untuk menyimpan lokasi laporan. Kakas bantu akan mengecek format dokumen yang akan disimpan. Jika tidak memenuhi format, kakas bantu memberikan peringatan untuk memilih lokasi, memberikan nama, dan memilih format laporan yang sesuai. Apabila format telah sesuai, kakas bantu akan menampilkan alamat, nama, dan format dokumen yang akan disimpan (file path) pada kolom lokasi penyimpanan hasil pemeriksaan ketidaksesuaian antarmuka utama kakas bantu. Lokasi terakhir di mana analis sistem memilih lokasi penyimpanan laporan juga disimpan, seperti pada proses memasukkan dokumen rancangan.

106

3.2.2.4

Proses Mengekstraksi Dokumen Rancangan

Ekstraksi dokumen rancangan dilakukan dengan mengambil alamat dokumen rancangan (file path) yang telah dimasukkan pada kakas bantu. Ekstraksi dokumen rancangan mengambil elemen diagram pada dokumen rancangan yang nantinya diperlukan untuk proses deteksi ketidaksesuaian dokumen rancangan. Elemen diagram tersebut antara lain: 1. Diagram kasus penggunaan (use case diagram) Elemen yang diambil pada diagram kasus penggunaan adalah nama kasus penggunaan (use case). 2. Deskripsi kasus penggunaan (use case description) Elemen yang diambil pada deskripsi kasus penggunaan adalah kalimat alur kejadian dasar (basic flow). 3. Diagram urutan (sequence diagram) Elemen yang diambil pada diagram urutan, antara lain judul diagram urutan, kelas-kelas yang ada pada diagram urutan, stereotype kelaskelas tersebut, nama method baik yang dikirim atau diterima oleh sebuah kelas, dan tipe method pada diagram urutan. Elemen-elemen tersebut bisa ditemukan melalui pemetaan dokumen rancangan yang dijabarkan oleh Tabel 3.16.

Tabel 3.16 Pemetaan elemen diagram dengan elemen dokumen rancangan (XMI) Elemen Diagram

Elemen XMI

Kasus penggunaan packagedElement (use case)

Atribut

name

Deskripsi Nilai atribut elemen ini menunjukkan nama kasus penggunaan. Ditandai dengan nilai

xmi:type atribut uml:UseCase.

107 Tabel 3.16 Pemetaan elemen diagram dengan elemen dokumen rancangan (XMI) (lanjutan) Elemen Diagram Deskripsi kasus penggunaan (use case description)

Frame

Elemen XMI

documentation

ownedMember

Atribut

Deskripsi

value

Nilai atribut elemen ini berisi kalimat alur kejadian dasar (basic flow).

name

Nilai atribut elemen ini menunjukkan judul diagram urutan (sequence diagram). Ditandai dengan nilai

xmi:type atribut uml:Interaction.

Lifeline

Stereotype kelas

Message

name

Nilai atribut elemen ini menunjukkan nama dari kelas.

xmi:id

Nilai atribut elemen ini berisi ID unik.

stereotype

value

Nilai atribut elemen ini berisi stereotype dari lifeline.

message

name

Nilai atribut elemen ini menunjukkan nama method.

lifeline

Nilai atribut elemen ini berisi ID unik dari sendEvent fragment yang mengirim method.

108 Tabel 3.16 Pemetaan elemen diagram dengan elemen dokumen rancangan (XMI) (lanjutan) Elemen Diagram

Elemen XMI

Atribut

Deskripsi Nilai atribut elemen

receive- ini berisi ID unik dari Event fragment yang

menerima method. Nilai atribut elemen ini berisi tipe method, messageseperti synchronous, Sort reply, dan create method. Fragment

fragment

xmi:id

Nilai atribut elemen ini berisi ID unik dari fragment.

covered

Nilai atribut elemen ini berisi ID unik dari lifeline.

Tabel 3.16 menunjukkan pemetaan antara elemen dokumen rancangan dengan elemen diagram. Kolom atribut merupakan penanda yang berisi informasi penting dari sebuah diagram pada dokumen rancangan. Sebuah elemen di dalam XMI memiliki banyak atribut. Tabel tersebut hanya menyebutkan beberapa atribut karena atribut yang disebutkan merupakan atribut kunci dari suatu elemen diagram pada dokumen rancangan. Untuk memberikan pemahaman atribut kunci tersebut, ada contoh elemen diagram beserta representasi elemen tersebut dalam XMI. Contoh dari masing-masing elemen diagram dijabarkan sebagai berikut: 1. Kasus penggunaan (use case) Sebuah kasus penggunaan mengandung informasi berupa nama kasus penggunaan tersebut. Sebagai contoh, diagram kasus penggunaan (use case diagram) “Online Shopping System” yang ditunjukkan oleh Gambar 3.11. Diagram tersebut terdiri dari seorang aktor bernama “Cus-

109 tomer” dan sebuah kasus penggunaan dengan nama “Buy a Product”. Contoh representasi diagram tersebut dalam XMI ditunjukkan oleh Kode Sumber 3.1.

Kode Sumber 3.1 Elemen diagram kasus penggunaan (use case diagram) “Online Shopping System” dalam XMI 1

2

<packagedElement xmi:id="AAAAAAFXdJDqJ22F/Bk=" name ,→ ="Buy a Product" visibility="public" ,→ isAbstract="false" isFinalSpecialization=" ,→ false" isLeaf="false" xmi:type="uml:UseCase" ,→ >

Kasus penggunaan ditunjukkan oleh elemen packagedElement dengan atribut kunci xmi:type bernilai uml:UseCase dan name dengan atribut bernilai Buy a Product pada potongan kode tersebut (baris ke-1). 2. Deskripsi kasus penggunaan (use case description) Deskripsi kasus penggunaan berisi kalimat alur kejadian dasar (basic flow). Kalimat tersebut dimasukkan ke dalam documentation pada sidebar editors aplikasi StarUML 2 sesuai penjelasan sebelumnya. Mengacu pada diagram kasus penggunaan “Online Shopping System”, kasus penggunaan “Buy a Product” memiliki deskripsi berupa kalimat alur kejadian (ditunjukkan oleh Gambar 3.12). Deskripsi yang telah dinormalisasi ini jika direpresentasikan ke dalam XMI tampak pada Kode Sumber 3.2.

Kode Sumber 3.2 Elemen deskripsi kasus penggunaan (use case description) “Buy a Product” dalam XMI 1

2 3

<packagedElement xmi:id="AAAAAAFXdJDqJ22F/Bk=" name ,→ ="Buy a Product" visibility="public" ,→ isAbstract="false" isFinalSpecialization=" ,→ false" isLeaf="false" xmi:type="uml:UseCase" ,→ > <xmi:Extension extender="StarUML"> <documentation value="Customer browses catalog. ,→ Customer selects item to buy. Customer ,→ goes to check out. Customer fills in ,→ shipping information. System presents ,→ full pricing information, including

110 ,→ ,→ ,→ ,→ ,→

4 5

shipping. Customer fills in credit card information. System authorizes purchase. System confirms sale immediately. System sends confirming e-mail to customer."/>

Deskripsi kasus penggunaan ditunjukkan oleh elemen documentation dengan atribut kunci value yang berisi kalimat alur kejadian (baris ke-3). 3. Diagram urutan (sequence diagram) Elemen diagram urutan yang diambil saat ekstraksi dokumen rancangan, antara lain judul diagram urutan, kelas-kelas (class) yang berinteraksi, dan nama method. Sebagai contoh, diagram urutan “Buy a Product” yang ditunjukkan oleh Gambar 3.13. Diagram tersebut memiliki judul “Buy a Product”. Representasi judul diagram tersebut dalam XMI ditunjukkan oleh Kode Sumber 3.3.

Kode Sumber 3.3 Elemen judul diagram urutan (sequence diagram) “Buy a Product” dalam XMI 1

2

3

<packagedElement xmi:id="AAAAAAFXdI/PbG0ufHY=" name ,→ ="Collaboration1" visibility="public" ,→ isAbstract="false" isFinalSpecialization=" ,→ false" isLeaf="false" xmi:type=" ,→ uml:Collaboration">

Terdapat elemen ownedMember dengan atribut kunci xmi:type bernilai uml:Interaction dan name yang bernilai Buy a Product (baris ke-2) yang menunjukkan judul diagram urutan. Selanjutnya, kelas-kelas yang berinteraksi pada diagram urutan. Kelas berisi informasi berupa nama kelas dan objek. Namun, ekstraksi

111 hanya mengambil nama kelas. Sebagai contoh, kelas “Customer” berinteraksi dengan kelas “BrowseInterface” pada diagram urutan “Buy a Product” yang ditunjukkan oleh Gambar 3.14. Kelas “Customer” merupakan kelas perwujudan aktor di dalam sistem, sedangkan kelas “BrowseInterface” merupakan kelas boundary yang menghubungkan antara aktor dengan sistem. Dalam XMI, elemen ini direpresentasikan oleh Kode Sumber 3.4.

Gambar 3.14 Contoh kelas (class) yang berinteraksi pada diagram urutan (sequence diagram) “Buy a Product” Kode Sumber 3.4 Elemen kelas (class) sebuah diagram urutan (sequence diagram) dalam XMI 1

2

3 4 5 6 7

8 9

<xmi:Extension extender="StarUML"> <stereotype value="actor"/> <xmi:Extension extender="StarUML"> <stereotype value="boundary"/>

112 10 11

Kelas yang berinteraksi ditunjukkan oleh elemen lifeline dengan atribut kunci xmi:type bernilai uml:Lifeline dan name yang bernilai : Customer (baris ke-2) dan : BrowseInterface (baris ke7). Stereotype kelas sendiri ditunjukkan oleh nilai atribut value pada elemen stereotype. Contoh, kelas “BrowseInterface” memiliki nilai boundary pada baris ke-9. Terakhir, pesan (message) pada diagram urutan. Pesan berupa sebuah method yang digunakan untuk berkomunikasi antara kelas satu dengan kelas lainnya. Sebagai contoh, terdapat method “browseItems” yang dikirim oleh kelas “Customer” dan diterima oleh kelas “BrowseInterface” pada Gambar 3.14. Jika method tersebut direpresentasikan ke dalam XMI, hasil tampak seperti Kode Sumber 3.5.

Kode Sumber 3.5 Elemen pesan (message) sebuah diagram urutan (sequence diagram) dalam XMI 1

2

3 4 5 6 7

8 9 10 11 12 13

<xmi:Extension extender="StarUML"> <stereotype value="actor"/> <xmi:Extension extender="StarUML"> <stereotype value="boundary"/> ... <message xmi:id="AAAAAAFXewsosPF06Q0=" name="

113 ,→ ,→ ,→ ,→ ,→

14

15 16

17

18

browseItems()" visibility="public" xmi:type="uml:Message" messageSort=" synchCall" messageKind="complete" receiveEvent="AAAAAAFYE8IkYOS3hlU=" sendEvent="AAAAAAFYE8IkYOS2fbU="/> <message xmi:id="AAAAAAFXewy/sfGLbiU=" name=" ,→ getItems()" visibility="public" xmi:type ,→ ="uml:Message" messageSort="synchCall" ,→ messageKind="complete" receiveEvent=" ,→ AAAAAAFYE8IkYeS5ELs=" sendEvent=" ,→ AAAAAAFYE8IkYeS4e6s="/> ... ...

Baris ke-13 dari Kode Sumber 3.5 menunjukkan elemen dari pesan “browseItems”. Pesan tersebut ditandai dengan elemen pesan dengan atribut kunci xmi:type bernilai uml:Message dan name yang bernilai browseItems(). Selain itu, atribut sendEvent dan receiveEvent juga perlu diperhatikan. Nilai atribut tersebut mengarah pada siapa kelas pengirim dan penerima sebuah pesan. Untuk mengetahui pengirim sebuah pesan, pengirim dilihat nilai dari sendEvent. Pesan “browseItems” sebagai contoh memiliki nilai sendEvent, yaitu “AAAAAAFYE8IkYOS2fbU=”. Nilai tersebut tidak langsung mengarah kepada xmi:id dari elemen lifeline tempat di mana ditemukannya nama sebuah kelas. Namun, nilai ini mengarah kepada xmi:id dari elemen fragment baris ke-16. Fragment tersebut memiliki nilai covered “AAAAAAFXewhKh/CDzVQ=”. Nilai ini mengarah pada xmi:id lifeline dari kelas “Customer” (baris ke-2). Sehingga, pengirim message “browseItems” adalah kelas “Customer”. Pengirim atau penerima message dapat diketahui dengan melihat nilai atribut sendEvent atau receiveEvent dari elemen pesan di mana nilai tersebut mengarah pada nilai atribut xmi:id dari elemen fragment. Nilai atribut covered yang ada pada fragment tersebut mengarah ke nilai atribut xmi:id dari elemen lifeline. Message “browseItems” memiliki

114 tipe method synchronous karena memiliki nilai atribut messageSort “synchCall”.

Gambar 3.15 Alur proses ekstraksi dokumen rancangan Proses ekstraksi yang telah dijelaskan sebelumnya dapat digambarkan melalui alur Gambar 3.15. Sesuai alur tersebut, proses ektraksi dokumen rancangan selesai saat semua elemen diagram yang dibutuhkan telah disimpan. Elemen diagram yang telah disimpan digunakan untuk mengelompokkan elemen diagram berdasarkan kasus penggunaan. Dari deskripsi kasus penggunaan yang telah didapatkan, deskripsi tersebut dikelompokkan berdasarkan kasus penggunaannya. Kelas-kelas yang berinteraksi melalui pesan pada diagram urutan disusun ke dalam bentuk triplet. Triplet terdiri dari nama kelas pengirim (sender

115 class), nama method yang dikirim, dan nama kelas penerima (receiver class). Kemudian, triplet-triplet tersebut dikelompokkan berdasarkan judul diagram urutannya karena judul diagram urutan merepresentasikan realisasi kasus penggunaan yang bersangkutan.

3.2.2.5 Proses Mendeteksi Ketidaksesuaian Proses mendeteksi ketidaksesuaian dokumen rancangan merupakan proses yang dilakukan setelah mengekstraksi dokumen rancangan. Hasil ekstraksi dokumen rancangan pada proses sebelumnya digunakan untuk proses ini. Hasil ekstraksi telah menampung elemen nama kasus penggunaan (use case), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram). Selain itu, elemen tersebut juga telah dikelompokkan berdasarkan kasus penggunaannya. Alur deteksi ketidaksesuaian dokumen rancangan digambarkan oleh Gambar 3.16. Alur tersebut dijelaskan sebagai berikut: 1. Mengambil satu kasus penggunaan dari elemen kasus penggunaan Sebuah diagram kasus penggunaan (use case diagram) terdiri dari satu atau lebih kasus penggunaan. Untuk memulai pengecekan kesesuaian diagram kasus penggunaan dengan diagram urutan, satu kasus penggunaan terlebih dahulu dicek. Misal, ada sebuah kasus penggunaan “Buy a Product”. Nama kasus penggunaan tersebut diambil. 2. Mengambil deskripsi kasus penggunaan dari kasus penggunaan yang diambil sebelumnya Sebuah kasus penggunaan memiliki deskripsi kasus penggunaan yang berisi alur kejadian kasus penggunaan. Dalam konteks ini, alur tersebut adalah alur kejadian dasar (basic flow). Alur tersebut berupa kalimat dialog antara aktor dan sistem. Dari nama kasus penggunaan yang telah diambil sebelumnya, deskripsi kasus penggunaannya diambil. Nama kasus penggunaan sebelumnya adalah “Buy a Product”. Sehingga, deskripsinya tampak dalam sebuah paragraf di bawah ini. Customer browses catalog. Customer selects item to buy. Customer goes to check out. Customer fills in shipping information. System presents full pricing information. Customer fills in credit card information. System authorizes purchase. System confirms sale immediately. System sends confirming e-mail to customer. 3. Memecah paragraf dari deskripsi kasus kasus penggunaan menjadi kalimat yang mandiri

116

Gambar 3.16 Alur proses deteksi ketidaksesuaian

Deskripsi kasus penggunaan yang telah diambil sebelumnya berupa paragraf yang berisi kalimat alur kejadian dasar. Paragraf tersebut dipecah menjadi kalimat-kalimat yang mandiri. Pemecahan paragraf menjadi kalimat yang mandiri dilakukan melalui sentence breaking. Sentence breaking adalah proses memecah paragraf menjadi kalimatkalimat tunggal yang disebut dengan token kalimat. Misal, deskripsi kasus penggunaan “Buy a Product” akan menjadi kalimat-kalimat (token) berikut ini: • Customer browses catalog. • Customer selects item to buy. • Customer goes to check out.

117 • Customer fills in shipping information. • System presents full pricing information. • Customer fills in credit card information. • System authorizes purchase. • System confirms sale immediately. • System sends confirming e-mail to customer. 4. Mengambil triplet dari diagram urutan yang berkorespondensi dengan kasus penggunaan sebelumnya Triplet terdiri dari kelas pengirim (sender class), nama pesan (method), dan kelas penerima (receiver class). Untuk mengambil triplet, pasangan diagram urutan yang merealisasikan kasus penggunaan saat ini harus ditemukan terlebih dahulu. Pasangan tersebut dapat ditemukan dengan menyesuaikan judul diagram urutan dengan nama kasus penggunaan. Setelah ditemukan, penentuan triplet yang diambil. Triplet yang diambil hanya triplet yang memiliki method dari aktor ke boundary class dan dari sistem ke boundary class (bisa dilihat dari stereotype kelas tersebut). Sehingga, diagram urutan dari kasus penggunaan saat ini, yaitu “Buy a Product” memiliki triplet berikut ini: • {Customer, browseItems, BrowseInterface} • {ItemController, items, BrowseInterface} • {Customer, selectItems, BrowseInterface} • {Customer, purchase, PurchaseInterface} • {BrowseInreface, selectedItems, PurchaseItems} • {ItemController, priceInfo, PurchaseInterface} • {PurchaseInterface, displaySelectedItems, PurchaseInterface} • {PurchaseInterface, displayPriceInfo, PurchaseInterface} • {Checkout, notification, PurchaseInterface} 5. Mengubah triplet menjadi kalimat Triplet diubah terlebih dahulu menjadi sebuah kalimat sebelum dihitung nilai kemiripannya dengan kalimat alur kejadian dasar kasus penggunaan. Pengubahan dilakukan dengan memisahkan penyusun nama kelas pengirim, nama method, dan nama kelas penerima dengan spasi. Kemudian, menggabungkan susunannya dengan lower-casing penyusun elemen triplet (kecuali singkatan atau akronim) dan menambah artikel “The” di awal kalimat. Kata kerja pada nama method bertipe synchronous ditambah akhiran “s” atau “es” dan artikel “the” setelah nama kata kerja tersebut. Pengubahan tidak dilakukan untuk method bertipe reply atau create. Sebagai contoh, triplet dari {Customer, browse-

118 Items, BrowseInterface} menjadi kalimat The customer browses the items browse interface. Kalimat harus diawali dengan huruf kapital dan diakhiri tanda titik. Penambahan “s” atau “es” pada kata kerja nama method dilakukan karena kata kerja tersebut dilakukan oleh orang ketiga tunggal. Baik aktor maupun sistem masuk ke dalam kategori orang ketiga tunggal. Pengubahan ini juga bertujuan agar hasil partof-speech tagging kalimat benar. Part-of-speech tagging dijelaskan pada proses selanjutnya.

3.2.2.6

Proses Menghitung Kemiripan Kalimat Alur Kejadian Dasar (Basic Flow) dan Triplet

Perhitungan kemiripan kalimat alur kejadian dasar kasus penggunaan dan triplet merupakan bagian dari proses mendeteksi ketidaksesuaian. Perhitungan dilakukan dengan pendekatan kemiripan semantik kalimat yang diajukan oleh Lee [14]. Alur dari pendekatan kemiripan kalimat ini digambarkan melalui Gambar 3.17. Alur dari gambar tersebut dijelaskan sebagai berikut: 1. Tahap pre-processing Tahap ini adalah tahap melakukan normalisasi pasangan kalimat. Normalisasi kalimat meliputi tokenization, lower-casing, stemming, dan stop-word removing. Pada kakas bantu yang dibuat, pasangan kalimat dilakukan tokenization terlebih dahulu. Tokenization adalah proses memecah teks atau kalimat menjadi kata-kata yang disebut dengan token. Token yang didapatkan kemudian harus diubah ke dalam huruf kecil melalui lower-casing. Untuk mendapatkan bentuk dasar dari kata, lemmatization perlu dilakukan. Lemmatization lebih dipilih dibandingkan dengan stemming karena lemmatization menghasilkan bentuk dasar suatu kata berdasarkan konteks kalimat (hubungan kata satu dengan kata lain dalam satu kalimat), sedangkan stemming tidak memperhatikan itu, hanya menghilangkan akhiran tertentu, seperti “ed”, “ing”, atau “ly” pada suatu kata. Contoh lemmatization, kata “better” memiliki bentuk dasar “good” sebagai lemma. Penghilangan kata yang tidak memiliki makna atau stop-word removing tidak dilakukan pada tahap ini agar tagging kalimat menghasilkan hasil yang sesuai. Kata yang tidak memiliki makna ini ditangani pada tahap selanjutnya. 2. Tahap menghimpun kata benda dan kata kerja Untuk mendapatkan himpunan kata benda dan kata kerja dari masing-

119

Gambar 3.17 Alur menghitung kemiripan kalimat alur kejadian dasar (basic flow) kasus penggunaan dan triplet

masing kalimat, part-of-speech tagging kalimat dilakukan. Hasil dari proses ini akan didapatkan part-of-speech (POS) dari setiap token masing-masing kalimat. Sesuai penjelasan pada Tabel 2.4, kata benda ditandai dengan penanda POS “NN”, “NNS”, “NNP”, dan “NNPS”, sedangkan kata kerja dengan penanda “VB”, “VBD”, “VBG”, “VBN”, “VBP”, dan “VBZ”. Mengambil contoh pasangan kalimat pertama, POS tagging kalimat Customer browses catalog. dan The customer browses items the browse interface. menghasilkan: Customer/NN browses/VBZ catalog/NN ./.

120 The/DT customer/NN browses/VBZ the/DT items/NNS browse/JJ interface/NN ./. Kata benda dan kata kerja didapatkan dari hasil POS tagging tersebut. Untuk memastikan kata yang memiliki penanda kata benda atau kata kerja adalah kata benda atau kata kerja, pengecekan kata melalui WordNet perlu dilakukan. Pengecekan kata termasuk dalam kategori stop-word juga sekaligus dilakukan untuk menangani kata yang tidak memiliki makna. Sehingga, himpunan kata benda kalimat pertama (S_NA ) adalah {customer, catalog} dan himpunan kata benda kalimat kedua (S_NB ) adalah {customer, item, interface}. Himpunan kata kerja kalimat pertama (S_VA ) adalah {browse} dan himpunan kata kerja kalimat kedua (S_VB ) adalah {browse}. Kata yang dimasukkan ke dalam himpunan adalah kata yang sudah melalui tokenization, lower-casing, dan lemmatization. 3. Tahap menghitung kemiripan kata Himpunan kata benda dan kata kerja yang telah didapatkan kemudian dihitung kemiripan katanya. Untuk menghitung kemiripan tersebut, himpunan kata benda dan kata kerja masing-masing kalimat dibandingkan dengan ruang semantik kata benda dan kata kerja. Ruang semantik kata benda (N _BASE) dan ruang semantik kata kerja (V _BASE) masing-masing adalah himpunan yang berisi gabungan himpunan kata benda (S_NA ) dan (S_NB ), dan gabungan himpunan kata kerja (S_VA ) dan (S_VB ). Sehingga, merujuk contoh sebelumnya, ruang semantik kata benda adalah {customer, catalog, item, interface} dan ruang semantik kata kerja adalah {browse}. Ilustrasi perhitungan untuk kalimat pertama dapat dilihat pada Tabel 3.17 dan 3.18. Metrik perhitungan kemiripan kata yang digunakan pada tahap ini adalah metrik kemiripan kata yang diajukan oleh Lin dengan Sánchez et al. sebagai model information content. Metrik ini menghasilkan nilai kemiripan kata pada rentang 0 hingga 1. Perhitungan kemiripan kata dengan cara yang sama dilanjutkan untuk kalimat kedua. 4. Tahap mendapatkan nilai vektor kata benda dan vektor kata kerja Vektor kata benda dan vektor kata kerja adalah sebuah vektor yang elemennya berisi nilai kemiripan kata paling tinggi dari setiap kolom perbandingan himpunan kata benda atau kata kerja dengan ruang semantik kata benda atau kata kerja. Vektor kata benda dinotasikan dengan N V , sedangkan vektor kata kerja dinotasikan dengan V V . Sehingga, dari hasil perhitungan sebelumnya, vektor kata benda kalimat

121 Tabel 3.17 Himpunan kata benda kalimat pertama dibanding ruang semantik kata benda S_NA customer catalog

N _BASE customer

catalog

item

interface

1,00 0,22

0,22 1,00

0,00 0,00

0,18 0,17

Tabel 3.18 Himpunan kata kerja kalimat pertama dibanding ruang semantik kata kerja S_VA browse

V _BASE browse 1,00

pertama (N VA ) adalah [1,00, 1,00, 0,00, 0,18] dan vektor kata kerja kalimat pertama (V VA ) adalah [1,00]. Cara yang sama diberlakukan pada kalimat kedua untuk mendapatkan vektor kata benda dan vektor kata kerjanya. 5. Tahap menghitung cosine similarity antara vektor kata benda dan vektor kata kerja Tahap ini menghitung sudut cosine antara vektor kata benda dan vektor kata kerja yang telah didapatkan dari kedua kalimat. Masing-masing dinotasikan dengan N C, noun cosine, dan V C, verb cosine. Perhitungan tersebut dihitung menggunakan Persamaan 2.2 dan 2.3. 6. Tahap menghitung nilai akhir kemiripan kalimat Nilai akhir kemiripan kalimat didapatkan dengan menggabungkan nilai vektor kata benda, N C, dan vektor kata kerja, V C. Perhitungan dihitung dengan menggunakan Persamaan 2.4. Setelah mendapatkan nilai kemiripan kalimat pasangan kalimat pertama, pasangan kalimat tersebut diberikan label “Sesuai” atau “Tidak se-

122 suai” berdasarkan ambang batas yang telah ditetapkan2 . Informasi pasangan kalimat dan label kesesuaian disimpan untuk nantinya ditampilkan pada antarmuka kakas bantu atau dieskpor ke bentuk laporan. Perhitungan kemudian dilanjutkan dengan pasangan berikutnya. Tidak semua pasangan kalimat alur kejadian dasar dan triplet dihitung kemiripannya. Terdapat aturan pasangan kalimat alur kejadian dasar dan triplet yang akan dihitung kemiripannya. Aturan tersebut dijelaskan sebagai berikut: • Jika nilai kemiripan kalimat pasangan kalimat alur kejadian dasar dan triplet memenuhi ambang batas yang telah ditentukan, pasangan diberikan label “Sesuai” dan perhitungan dilanjutkan oleh pasangan kalimat dan triplet berikutnya. • Jika nilai kemiripan kalimat tidak memenuhi ambang batas yang telah ditentukan, menghitung nilai kemiripan kalimat alur kejadian dasar yang belum memenuhi tersebut dengan triplet berikutnya. • Jika hingga triplet terakhir nilai kemiripan kalimat tidak ada yang memenuhi, pasangan diberikan label “Tidak sesuai” dan perhitungan dilanjutkan oleh kalimat alur kejadian dasar berikutnya dan triplet yang belum memenuhi setelah triplet terakhir yang memenuhi. Sebagai ilustrasi, misal terdapat kalimat alur kejadian dasar A1 , A2 , dan A3 serta triplet T1 , T2 , T3 , T4 , dan T5 . Kemiripan kalimat A1 dan T1 memenuhi ambang batas kemiripan. Kalimat A1 dan T1 diberikan label “Sesuai” dan perhitungan kemiripan dilanjutkan oleh kalimat A2 dan T2 . Hasil kemiripan kedua kalimat tersebut ternyata tidak memenuhi ambang batas kemiripan. Perhitungan dilanjutkan dengan tetap menghitung kalimat A2 , namun dengan T3 . Hasil kemiripan kalimat A2 dan T3 memenuhi ambang batas kemiripan. Kalimat A2 dan T3 diberikan label “Sesuai” dan perhitungan kemiripan dilanjutkan oleh kalimat A3 dan T4 , bukan A3 dan T2 . Walaupun T2 merupakan triplet yang belum memenuhi, posisi T2 berada sebelum T3 di mana merupakan triplet terakhir yang memenuhi. T4 diambil karena merupakan triplet yang belum memenuhi dan memiliki posisi setelah triplet terakhir yang memenuhi, T3 . Ternyata, hasil kemiripan kedua kalimat tersebut memenuhi ambang batas. Kalimat A3 dan T4 diberikan label “Sesuai”. Masih ada T5 yang belum dihitung kemiripannya dengan kalimat alur kejadian. Karena semua kalimat alur kejadian sudah dihitung kemiripannya, T5 diberikan label “Tidak sesuai”. 2

Nilai ambang batas kemiripan kalimat ditentukan berdasarkan hasil pengujian data pelatihan (training data). Nilai ini berada pada rentang 0 hingga 1.

123

3.2.2.7 Proses Menampilkan Hasil Deteksi Ketidaksesuaian Dari perhitungan kemiripan semantik kalimat alur kejadian dasar dan triplet, pasangan kalimat alur kejadian dan triplet yang memiliki label “Sesuai” dan “Tidak sesuai” telah disimpan. Data tersebut kemudian diambil dan ditampilkan pada antarmuka utama kakas bantu sebagai hasil deteksi ketidaksesuaian. Data yang ditampilkan berupa daftar yang terdiri dari nama kasus penggunaan (use case), daftar kalimat alur kejadian dasar (basic flow) kasus penggunaan, dan daftar triplet. Penanda kesesuaian dibedakan dengan memberikan warna pada kalimat alur kejadian dasar kasus penggunaan dan triplet. Warna hijau diberikan untuk penanda dengan label “Sesuai”, sedangkan warna merah diberikan untuk penanda dengan label “Tidak sesuai”. Mengambil ilustrasi sebelumnya, kalimat alur kejadian dasar A1 , A2 , A3 , dan triplet T1 , T3 , T4 ditampilkan dengan teks berwarna hijau. Triplet T2 dan T5 ditampilkan dengan teks berwarna merah.

3.2.2.8 Proses Mengekspor Hasil Deteksi dalam Bentuk Laporan Proses ini dikerjakan apabila opsi ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan pada antarmuka utama kakas bantu dicentang. Laporan dibuat pada lokasi yang telah ditentukan dengan nama berkas yang telah diberikan ditambah nama kasus penggunaan dan format “.doc”, “.docx”, atau “.pdf”. Hasil deteksi ketidaksesuaian dalam bentuk laporan tidak jauh berbeda dengan hasil deteksi ketidaksesuaian yang ditampilkan pada antarmuka utama kakas bantu. Hasil deteksi dalam bentuk laporan berisi daftar berurutan yang berisi nama kasus penggunaan (use case), kalimat alur kejadian dasar (basic flow) kasus penggunaan baik dengan label “Sesuai” maupun “Tidak sesuai”, dan triplet baik dengan label “Sesuai” maupun “Tidak sesuai”. Sehingga, melanjutkan ilustrasi sebelumnya, laporan berisi daftar kalimat A1 , A2 , dan A3 serta daftar triplet T1 , T2 , T3 , T4 , dan T5 . Label “Sesuai” atau “Tidak sesuai” dapat dibedakan dengan memberikan warna pada daftar tersebut. Misal, hijau untuk label “Sesuai” dan merah untuk label “Tidak sesuai”. Tanggal dan waktu pemeriksaan ketidaksesuaian dengan kakas bantu juga dimasukkan ke dalam laporan. Jika dokumen berancangan berisi lebih dari satu kasus penggunaan, laporan hasil deteksi dibuat terpisah sesuai jumlah kasus penggunaan.

124

3.2.3

Perancangan Diagram Kelas (Class Diagram)

Hasil analisis kandidat kelas yang telah dilakukan sebelumnya juga digunakan untuk merancang diagram kelas kakas bantu. Diagram kelas adalah diagram yang menggambarkan kelas-kelas (class) yang menyusun sistem dan hubungan antar kelas-kelas tersebut. Diagram kelas disusun berdasarkan hasil model analisis setiap kasus penggunaan (use case). Karena diagram kelas terlalu kompleks, diagram kelas setiap kasus penggunaan didetailkan lagi ke dalam proses-proses yang terjadi di dalam kakas bantu. Penjelasan diagram kelas dari kakas bantu yang dikelompokkan berdasarkan kasus penggunaan dijelaskan sebagai berikut:

3.2.3.1

Diagram Kelas Memeriksa Ketidaksesuaian Dokumen Rancangan

Diagram kelas untuk kasus penggunaan “Memeriksa Ketidaksesuaian Dokumen Rancangan” didapatkan dari hasil analisis kandidat kelas sebelumnya. Selain itu, terdapat kelas-kelas lain yang tidak disebutkan saat analisis kandidat kelas karena kelas tersebut merupakan kelas tambahan yang dibutuhkan saat proses memeriksa ketidaksesuaian dokumen rancangan. Diagram kelas dijelaskan lebih detail berdasarkan proses yang terjadi saat kasus penggunaan dijalankan. Penjelasan tersebut dijelaskan sebagai berikut: 1. Proses Memasukkan Dokumen Rancangan Terdapat tiga kelas utama pada proses memasukkan dokumen rancangan, yaitu kelas “MainGui”, kelas “FileChooserDialog”, dan kelas “FileHandler”. Kelas “MainGui” adalah kelas perwujudan antarmuka utama dari kakas bantu. Kelas ini mewarisi kelas “javax.swing.JFrame” sebagai sebuah jendela aplikasi yang memiliki komponen, seperti judul jendela dan tombol (button). Kelas “FileChooserDialog” merupakan perwujudan antarmuka untuk memasukkan dokumen rancangan ke dalam kakas bantu. Kelas ini mewarisi kelas “javax.swing.JFileChooser” yang menyediakan mekanisme pemilihan berkas. Kelas “FileHandler” membantu kelas “FileChooserDialog” untuk mengatur berkas dokumen rancangan yang dimasukkan ke dalam kakas bantu. Hubungan dari kelas-kelas tersebut digambarkan oleh Gambar 3.18, sedangkan penjelasan atribut dan operasi dari tiga kelas utama tersebut dijelaskan oleh Tabel 3.19.

125

Gambar 3.18 Kelas diagram (class diagram) proses memasukkan dokumen rancangan Tabel 3.19 Atribut dan operasi kelas (class) pada proses memasukkan dokumen rancangan Kelas

Atribut/Operasi

Deskripsi

MainGui

masukanBerkasButton

Tombol untuk memasukkan dokumen rancangan.

simpanHasilButton

Tombol untuk memilih lokasi penyimpanan hasil deteksi dalam bentuk laporan.

lakukanDeteksi

Tombol untuk melakukan deteksi ketidaksesuaian dokumen rancangan yang telah dimasukkan.

opsiEksporHasilLaporan

Kotak centang untuk mengaktifkan pilihan mengekspor hasil deteksi ke bentuk laporan.

126 Tabel 3.19 Atribut dan operasi kelas (class) pada proses memasukkan dokumen rancangan (lanjutan) Kelas

FileChooserDialog

Atribut/Operasi

Deskripsi

filePathDokumenRancangan

Kotak teks untuk menampilkan alamat berkas dokumen rancangan yang dimasukkan.

filePathLaporanHasilDeteksi

Kotak teks untuk menampilkan alamat berkas laporan hasil deteksi disimpan.

detailHasilDeteksi

Area untuk menampilakn hasil deteksi ketidaksesuaian dokumen rancangan.

MainGui()

Bertugas sebagai constructor method.

clickMasukanBerkasButton()

Bertugas menangani tindakan saat “masukanBerkasButton” ditekan dengan memanggil kelas “FileChooserDialog”.

showFilePath()

Bertugas menampilkan alamat berkas dokumen rancangan atau laporan hasil deteksi ketidaksesuaian pada kotak teks.

clickLakukanDeteksiButton

Bertugas menangani tindakan saat “lakukanDeteksi” ditekan.

main()

Bertugas sebagai main method, operasi yang dikerjakan saat kelas dijalankan.

chooseFile()

Bertugas untuk menetapkan berkas yang dipilih.

showFileChooserDialog()

Bertugas menampilkan jendela untuk memasukkan dokumen rancangan.

127 Tabel 3.19 Atribut dan operasi kelas (class) pada proses memasukkan dokumen rancangan (lanjutan) Kelas

FileHandler

Atribut/Operasi

Deskripsi

clickOpenButton()

Bertugas memasukkan dokumen rancangan yang dipilih.

getFile()

Bertugas mengambil berkas.

checkFileFormat()

Bertugas mengecek apakah format berkas sesuai dengan format yang telah ditentukan.

getFilePath()

Bertugas mendapatkan alamat berkas.

2. Proses Mengekstraksi Dokumen Rancangan Proses ini terdiri dari tiga kelas utama dan lima kelas model. Kelas utama, di antaranya kelas “UcdSdInconsistencyDetector”, kelas “XmiParser”, dan kelas “XmiParsingHandler”. Kelas “UcdSdInconsistencyDetector” bertugas untuk mengatur deteksi ketidaksesuaian dari dokumen rancangan yang telah dimasukkan ke dalam kakas bantu, kelas “XmiParser” merupakan kelas yang mengatur ekstraksi elemen diagram pada dokumen rancangan, dan kelas “XmiParsingHandler” yang menjalankan proses ekstraksi tersebut. Setiap hasil ekstraksi elemen diagram pada dokumen rancangan disimpan ke dalam kelas model. Kelas model tersebut, antara lain kelas “PackagedElement”, kelas “OwnedMemberElement”, kelas “LifeLineElement”, kelas “MessageElement”, dan kelas “FragmentElement”. Kalimat alur kejadian dasar pada deskripsi kasus penggunaan (use case description) dan elemen stereotype dari lifeline tidak dibuatkan kelas model sendiri, namun hanya disimpan dalam bentuk list of string. Hubungan dari kelas-kelas tersebut ditunjukkan oleh Gambar 3.19, sedangkan atribut dan operasi kelas dijelaskan oleh Tabel 3.20

128

Gambar 3.19 Kelas diagram (class diagram) proses mengekstraksi dokumen rancangan Tabel 3.20 Atribut dan operasi kelas (class) pada proses mengekstraksi dokumen rancangan Kelas

Atribut/Operasi

Deskripsi


doInconsistencyDetection()

Bertugas untuk melakukan deteksi ketidaksesuaian dokumen rancangan yang telah dimasukkan ke dalam kakas bantu.

129 Tabel 3.20 Atribut dan operasi kelas (class) pada proses mengekstraksi dokumen rancangan (lanjutan) Kelas

Atribut/Operasi

Deskripsi

XmiParser

xmiParsingHandler

Atribut dari kelas “XmiParsingHandler”.

XmiParser()


extractDesignFile()

Bertugas untuk melakukan ekstraksi dokumen rancangan.

packagedElement

Atribut dari kelas “PackagedElement”.

ownedMemberElement

Atribut dari kelas “OwnedMemberElement”.

lifeLineElement

Atribut dari kelas “LifeLineElement”.

fragmentElement

Atribut dari kelas “FragmentElement”.

messageElement ucdList

Atribut dari kelas “MessageElement”. Berisi list dari kalimat alur kejadian dasar pada deskripsi kasus penggunaan (use case description).

packagedElementList

Berisi list dari kelas “PackagedElement”.

ownedMemberElementList

Berisi list dari kelas “OwnedMemberElement”.

lifeLineElementList

Berisi list dari kelas “LifeLineElement”.

messageElementList

Berisi list dari kelas “MessageElement”.

XmiParsingHandler


Atribut/Operasi

Deskripsi

fragmentElementList

Berisi list dari kelas “FragmentElement”.

stereotypeList

Berisi list dari lifeline stereotype.

startElement()

Bertugas untuk memberikan notifikasi elemen awal untuk ekstraksi.

endElement()

Bertugas untuk memberikan notifikasi elemen akhir untuk ektraksi.

getPackagedList()

Bertugas untuk mendapatkan list dari kelas “PackagedElement”.

getUcdList()

Bertugas untuk mendapatkan list dari kalimat alur kejadian dasar pada deskripsi kasus penggunaan (use case description).

getOwnedMemberList()

Bertugas untuk mendapatkan list dari kelas “OwnedMemberElement”.

getLifeLineList()

Bertugas untuk mendapatkan list dari kelas “LifeLineElement”.

getPackagedList()

Bertugas untuk mendapatkan list dari kelas “PackagedElement”.

getMessageList()

Bertugas untuk mendapatkan list dari kelas “MessageElement”.

getFragmentList()

Bertugas untuk mendapatkan list dari kelas “FragmentElement”.

getStereotypeList()

Bertugas untuk mendapatkan list dari lifeline stereotype.


Atribut/Operasi

Deskripsi

PackagedElement

type

Berisi nilai atribut “xmi:type” dari elemen “packagedElement”.

name

Berisi nilai atribut “name” dari elemen “packagedElement”.

setType()

Bertugas untuk menentukan nilai atribut “type”.

getType()

Bertugas untuk mendapatkan nilai atribut “type”.

setName()

Bertugas untuk menentukan nilai atribut “name”.

getName()

Bertugas untuk mendapatkan nilai atribut “name”.

type

Berisi nilai atribut “xmi:type” dari elemen “ownedMember”.

name

Berisi nilai atribut “name” dari elemen “ownedMember”.

collaborationNumber

Berisi nilai urutan diagram urutan (sequence diagram).

setType()


getType()


setName()


getName()


OwnedMemberElement


LifeLineElement

MessageElement

Atribut/Operasi

Deskripsi

setCollaborationNumber()

Bertugas untuk menentukan nilai atribut “collaborationNumber”.

getCollaborationNumber()

Bertugas untuk mendapatkan nilai atribut “collaborationNumber”.

id

Berisi nilai atribut “xmi:id” dari elemen “lifeline”.

name

Berisi nilai atribut “name” dari elemen “lifeline”.

collaborationNumber


setId()

Bertugas untuk menentukan nilai atribut “id”.

getId()

Bertugas untuk mendapatkan nilai atribut “id”.

setName()


getName()






name

Berisi nilai atribut “name” dari elemen “message”.

senderId

Berisi nilai atribut “sendEvent” dari elemen “message”.


Atribut/Operasi

Deskripsi

receiverId

Berisi nilai atribut “receiveEvent” dari elemen “message”.

collaborationNumber


type

Berisi nilai atribut “messageSort” dari elemen “message”.

setName()


getName()


setSenderId()

Bertugas untuk menentukan nilai atribut “senderId”.

getSenderId()

Bertugas untuk mendapatkan nilai atribut “senderId”.

setReceiverId()

Bertugas untuk menentukan nilai atribut “receiverId”.

getReceiverId()

Bertugas untuk mendapatkan nilai atribut “receiverId”.





setType()


getType()



Atribut/Operasi

Deskripsi

FragmentElement

id

Berisi nilai atribut “xmi:id” dari elemen “fragment”.

type

Berisi nilai atribut “xmi:type” dari elemen “fragment”.

coveredId

Berisi nilai atribut “covered” dari elemen “fragment”.

collaborationNumber


setId()

Bertugas untuk menentukan nilai atribut “id”.

getId()

Bertugas untuk mendapatkan nilai atribut “id”.

setType()


getType()


setCoveredId()

Bertugas untuk menentukan nilai atribut “coveredId”.

getCoveredId()

Bertugas untuk mendapatkan nilai atribut “coveredId”.





135

Gambar 3.20 Kelas diagram (class diagram) proses mendeteksi ketidaksesuaian 3. Proses Mendeteksi Ketidaksesuaian Proses mendeteksi ketidaksesuaian terdiri dari dua kelas utama dan enam kelas model. Kelas utama tersebut, yaitu “UcdSdInconsistencyDetector” dan kelas “XmiParser”. Mengacu penjelasan sebelumnya, kedua kelas ini masing-masing bertugas untuk mengatur deteksi ketidaksesuaian dari dokumen rancangan yang dimasukkan ke dalam kakas bantu dan ekstraksi elemen diagram pada dokumen rancangan. Hasil ekstraksi dari proses ekstraksi dokumen rancangan diatur dan dikelompokkan untuk mendapatkan elemen kalimat deskripsi kasus pengguna-

136 an (use case description) dan diagram urutan (sequence diagram) yang sesuai. Elemen tersebut disimpan ke dalam kelas model, seperti kelas “UseCaseDescription” dan kelas “SequenceDiagram”. Kelas “SequenceDiagram” terdiri dari model kelas “SequenceDiagramClass”, kelas “SequenceDiagramMethod”, dan kelas “SequenceDiagramFragment”. Triplet dari diagram urutan disimpan dalam kelas “Triplet”. Hubungan kelas-kelas tersebut ditunjukkan oleh Gambar 3.20, sedangkan penjelasan atribut dan operasi kelas dijabarkan oleh Tabel 3.21.

Tabel 3.21 Atribut dan operasi kelas (class) pada proses mendeteksi ketidaksesuaian Kelas

Atribut/Operasi

Deskripsi


ucdList

Berisi list kalimat deskripsi kasus penggunaan (use case description).

triplet

Berisi list dari triplet.

doInconsistencyDetection()

Bertugas untuk memulai deteksi ketidaksesuaian dokumen rancangan.

groupUcfByUseCase()

Bertugas mengelompokkan kalimat deskripsi kasus penggunaan sesuai dengan kasus penggunaannya.

getUcfByUseCase()

Bertugas untuk mendapatkan kalimat deskripsi kasus penggunaan berdasarkan kasus penggunaan.

groupTripletBySequenceDiagram() getTripletBySequenceDiagram()

Bertugas untuk mengelompokkan triplet ke dalam diagram urutannya (sequence diagram). Bertugas untuk mendapatkan triplet berdasarkan nilai urutan diagram urutan.

137 Tabel 3.21 Atribut dan operasi kelas (class) pada proses mendeteksi ketidaksesuaian (lanjutan) Kelas

XmiParser

Atribut/Operasi

Deskripsi

calcuateUcfTriplet()

Bertugas untuk menghitung kesesuaian antara kalimat deskripsi kasus penggunaan dengan triplet.

getUseCaseName()

Bertugas untuk mendapatkan daftar nama kasus penggunaan.

getUseCaseDescription()

Bertugas untuk mendapatkan daftar deskripsi kasus penggunaan.

getSequenceDiagram()

Bertugas untuk mendapatkan daftar diagram urutan.

getSequenceDiagramClass()

Bertugas untuk mendapatkan daftar kelas diagram urutan.

getSequenceDiagramMethod()

Bertugas untuk mendapatkan daftar method diagram urutan.

getSequenceDiagramFragment()

Bertugas untuk mendapatkan daftar elemen “fragment” diagram urutan.

getSequenceDiagramTitle()

Bertugas untuk mendapatkan daftar judul diagram urutan.

getClassBySequenceDiagram()

Bertugas untuk mendapatkan daftar kelas berdasarkan diagram urutan.

getMethodBySequenceDiagram()

Bertugas untuk mendapatkan daftar method berdasarkan diagram urutan (sequence diagram).

getFragmentBySequenceDiagram()

Bertugas untuk mendapatkan daftar elemen “fragment” berdasarkan diagram urutan.


Atribut/Operasi

Deskripsi

UseCaseDescription

useCaseNumber

Berisi nilai urutan deskripsi kasus penggunaan.

useCaseName

Berisi nama kasus penggunaan dari deskripsi kasus penggunaan.

useCaseFlow

Berisi kalimat alur dasar (basic flow) dari deskripsi kasus penggunaan.

setUseCaseNumber()

Bertugas menentukan nilai atribut “useCaseNumber”.

getUseCaseNumber()

Bertugas mendapatkan nilai atribut “useCaseNumber”.

setUseCaseName()

Bertugas menentukan nilai atribut “useCaseName”.

getUseCaseName()

Bertugas mendapatkan nilai atribut “useCaseName”.

setUseCaseFlow()

Bertugas menentukan nilai atribut “useCaseFlow”.

getUseCaseFlow() title

Bertugas mendapatkan nilai atribut “useCaseFlow”. Berisi judul diagram urutan.

listOfClass

Berisi list dari kelas “SequenceDiagramClass”.

listOfMethod

Berisi list dari kelas “SequenceDiagramMethod”.

listOfFragment

Berisi list dari kelas “SequenceDiagramFragment”.

SequenceDiagram


SequenceDiagramClass

Atribut/Operasi

Deskripsi

setTitle()

Bertugas menentukan nilai atribut “title”.

getTitle()

Bertugas mendapatkan nilai atribut “title”.

setListOfClass()

Bertugas menentukan nilai atribut “listOfClass”.

getListOfClass()

Bertugas mendapatkan nilai atribut “listOfClass”.

setListOfMethod()

Bertugas menentukan nilai atribut “listOfMethod”.

getListOfMethod()

Bertugas mendapatkan nilai atribut “listOfMethod”.

setListOfFragment()

Bertugas menentukan nilai atribut “listOfFragment”.

getListOfFragment()

Bertugas mendapatkan nilai atribut “listOfFragment”.

sequenceDiagramNumber

Berisi nilai urutan diagram urutan, sebuah class termasuk dalam urutan diagram urutan ke berapa.

id

Berisi nilai ID dari class.

name

Berisi nama class.

stereotype

Berisi stereotype dari class.

setSequenceDiagramNumber()

Bertugas menentukan nilai atribut “sequenceDiagramNumber”.

getSequenceDiagramNumber()

Bertugas mendapatkan nilai atribut “sequenceDiagramNumber”.


SequenceDiagramMethod

Atribut/Operasi

Deskripsi

setId()

Bertugas menentukan nilai atribut “id”.

getId()

Bertugas mendapatkan nilai atribut “id”.

setName()

Bertugas menentukan nilai atribut “name”.

getName()

Bertugas mendapatkan nilai atribut “name”.

setStereotype()

Bertugas menentukan nilai atribut “stereotype”.

getStereotype()

Bertugas mendapatkan nilai atribut “stereotype”.


Berisi nilai urutan diagram urutan, sebuah method termasuk dalam urutan diagram urutan ke berapa.

senderId

Berisi nilai ID dari class yang mengirimkan method.

receiverId

Berisi nilai ID dari class yang menerima method.

name

Berisi nama method.

type

Berisi tipe method, misal synchronous atau reply method.






SequenceDiagramFragment

Atribut/Operasi

Deskripsi

setSenderId()

Bertugas menentukan nilai atribut “senderId”.

getSenderId()

Bertugas mendapatkan nilai artibut “senderId”.

setReceiverId()

Bertugas menentukan nilai atribut “receiverId”.

getReceiverId()

Bertugas mendapatkan nilai atribut “receiverId”.

setName()

Bertugas menentukan nilai atribut “name”.

getName()

Bertugas mendapatkan nilai atribut “name”.

setStereotype()

Bertugas menentukan nilai atribut “stereotype”.

getStereotype()

Bertugas mendapatkan nilai atribut “stereotype”.


Berisi nilai urutan diagram urutan, sebuah fragment termasuk dalam urutan diagram urutan ke berapa.

id

Berisi nilai ID dari fragment.

coveredId

Berisi nilai covered ID dari fragment.






Triplet

Atribut/Operasi

Deskripsi

setId()

Bertugas menentukan nilai atribut “id”.

getId()

Bertugas mendapatkan nilai atribut “id”.

setCoveredId()

Bertugas menentukan nilai atribut “coveredId”.

getCoveredId()

Bertugas mendapatkan nilai atribut “coveredId”.

firstValue

Berisi nilai pertama dari triplet.

secondValue

Berisi nilai kedua dari triplet.

thirdValue

Berisi nilai ketiga dari triplet.

setFirstValue()

Bertugas menentukan nilai atribut “firstValue”.

getFirstValue()

Bertugas mendapatkan nilai atribut “firstValue”.

setSecondValue()

Bertugas menentukan nilai atribut “secondValue”.

getSecondValue()

Bertugas mendapatkan nilai atribut “secondValue”.

setThirdValue()

Bertugas menentukan nilai atribut “thirdValue”. Bertugas mendapatkan nilai atribut “thirdValue”.

getThirdValue()

4. Proses Menghitung Kemiripan Kalimat Alur Kejadian Dasar (Basic Flow) dengan Triplet Proses menghitung kemiripan antara kalimat alur kejadian dasar pada deskripsi kasus penggunaan (use case description) dan triplet ditangani

143 oleh kelas “MingCheLeeSemanticSimilarity”. Kelas tersebut mengimplementasikan kelas interface “SentenceSimilarityScorer”. Selain itu, kelas ini menggunakan kelas “LinWordSimilarity” untuk menghitung kemiripan semantik antar kata. Kelas “LinWordSimilarity” mengimplementasikan kelas interface “WordSimilarityScorer”. Penyediaan kelas interface dilakukan agar memudahkan implementasi perhitungan kemiripan kalimat atau kata dengan pendekatan lainnya di kemudian hari. Hubungan kelas-kelas ini ditunjukkan oleh Gambar 3.21, sedangkan atribut dan operasi dari masing-masing kelas selanjutnya dijelaskan oleh Tabel 3.22.

Gambar 3.21 Kelas diagram (class diagram) proses menghitung kemiripan kalimat alur kejadian dasar (basic flow) dan triplet

Tabel 3.22 Atribut dan operasi kelas (class) pada proses menghitung kemiripan kalimat alur kejadian dasar dan triplet Kelas

Atribut/Operasi

Deskripsi


similarity()

Bertugas sebagai definisi abstract method untuk menghitung kemiripan kalimat.

MingCheLeeSemanticSimilarity

linWordSimilarity

Atribut dari kelas “LinWordSimilarity”.

144 Tabel 3.22 Atribut dan operasi kelas (class) pada proses menghitung kemiripan kalimat alur kejadian dasar dan triplet Kelas

Atribut/Operasi

Deskripsi

similarity()

Bertugas mengimplementasikan abstract method untuk menghitung nilai kemiripan semantik kalimat dengan metode Lee.


similarity()

Bertugas sebagai definisi abstract method untuk menghitung kemiripan kata.

LinWordSimilarity

similarity()

Bertugas mengimplementasikan abstract method untuk menghitung nilai kemiripan semantik kata dengan metrik Lin.

5. Proses Menampilkan Hasil Deteksi Ketidaksesuaian Proses ini adalah proses menampilkan hasil deteksi ketidaksesuaian pada area detail hasil deteksi antarmuka utama kakas bantu. Karena ditampilkan pada antarmuka utama kakas bantu, proses ini melibatkan kelas “MainGui”. Kelas “UcdSdInconsistencyDetector” juga ikut berperan dalam proses ini. Terdapat kelas utama yang terlibat pada proses ini, yaitu kelas “RowDetectionResult” dan kelas “UcdSdDetectionResult”. Setiap hasil deteksi ketidaksesuaian pasangan kalimat alur kejadian dasar kasus penggunaan dan triplet disimpan oleh kelas model “RowDetectionResult”. Kelas “UcdSdDetectionResult” adalah kelas yang bertugas menyimpan keseluruhan hasil deteksi ketidaksesuaian yang nantinya ditampilkan pada antarmuka utama kakas bantu. Selain itu, terdapat kelas “DetectionResultUtil” yang membantu mengubah hasil dari kelas “RowDetectionResult” menjadi hasil dalam bentuk daftar yang disimpan ke dalam kelas “UcdSdDetectionResult”. Hubungan kelas-kelas tersebut ditunjukkan oleh Gambar 3.22 dan atribut dan operasi dari kelas-kelas tersebut dijelaskan oleh Tabel 3.23. Penjelasan pada tabel hanya menjelaskan bagian dari kelas yang belum dijelaskan pada bagian sebelumnya.

145

Gambar 3.22 Kelas diagram (class diagram) proses menampilkan hasil deteksi ketidaksesuaian

Tabel 3.23 Atribut dan operasi kelas (class) pada proses menampilkan hasil deteksi ketidaksesuaian Kelas

Atribut/Operasi

Deskripsi

RowDetectionResult

useCaseName

Berisi nama kasus penggunaan (use case).

146 Tabel 3.23 Atribut dan operasi kelas (class) pada proses menampilkan hasil deteksi ketidaksesuaian (lanjutan) Kelas

DetectionResultUtil

Atribut/Operasi

Deskripsi

useCaseDescription

Berisi kalimat deskripsi kasus penggunaan (use case description).

triplet

Berisi triplet.

label

Berisi label kesesuaian, “Sesuai” atau “Tidak sesuai”.

setUseCaseName()


getUseCaseName()


setUseCaseDescription()

Bertugas menentukan nilai atribut “useCaseDescription”.


Bertugas mendapatkan nilai atribut “useCaseDescription”.

setTriplet()

Bertugas menentukan nilai atribut “triplet”.

getTriplet()

Bertugas mendapatkan nilai atribut “triplet”.

setLabel()

Bertugas menentukan nilai atribut “label”.

getLabel()

Bertugas mendapatkan nilai atribut “label”.

getUcdDetectionResult()

Bertugas mendapatkan daftar kalimat alur kejadian dasar kasus penggunaan yang telah dideteksi yang disimpan oleh kelas “RowDetectionResult”.


UseCaseDescriptionDetectionResult

DetectedUseCaseDescription

Atribut/Operasi

Deskripsi

getTripletDetectionResult()

Bertugas mendapatkan daftar triplet yang telah dideteksi yang disimpan oleh kelas “RowDetectionResult”.

useCaseName


detectedUseCaseDescription

Berisi list dari kelas “DetectedUseCaseDescription”.

setUseCaseName()


getUseCaseName()


setDetectedUseCaseDescription()

Bertugas menentukan nilai atribut “detectedUseCaseDescription”.

getDetectedUseCaseDescription()

BErtugas mendapatkan nilai atribut “detectedUseCaseDescription”.

useCaseDescription

Berisi kalimat alur kejadian dasar pada deskripsi kasus penggunaan yang telah dideteksi ketidaksesuaiannya.

label





TripletDetectionResult

DetectedTriplet

Atribut/Operasi

Deskripsi



setLabel()


setLabel()


useCaseName


detectedTriplet

Berisi list dari kelas “DetectedTriplet”.

setUseCaseName()


getUseCaseName()


setDetectedTriplet()

Bertugas menentukan nilai atribut “detectedTriplet”.

getDetectedTriplet()

Bertugas mendapatkan nilai atribut “detectedTriplet”.

triplet

Berisi triplet yang telah dideteksi ketidaksesuaiannya.

label


setTriplet()

Bertugas menentukan nilai atribut “triplet”.

getTriplet()

Bertugas mendapatkan nilai atribut “triplet”.



Atribut/Operasi

Deskripsi

setLabel()


getLabel()


useCaseDescriptionDetectionResult

Berisi daftar kalimat alur kejadian dasar pada deskripsi kasus penggunaan hasil deteksi ketidaksesuaian.

tripletDetectionResult

Berisi daftar triplet hasil deteksi ketidaksesuaian.

setUseCaseDescriptionDetectionResult()

Bertugas menentukan nilai atribut “useCaseDescriptionDetectionResult”.

getUseCaseDescriptionDetectionResult()

Bertugas mendapatkan nilai atribut “useCaseDescriptionDetectionResult”.

setTripletDetectionResult()

Bertugas menentukan nilai atribut “tripletDetectionResult”.

getTripletDetectionResult()

Bertugas mendapatkan nilai atribut “tripletDetectionResult”.

3.2.3.2 Diagram Kelas Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian Diagram kelas pada kasus penggunaan “Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” juga merupakan hasil analisis kandidat kelas sebelumnya. Tidak jauh berbeda dengan penjelasan diagram kelas sebelumnya, diagram kelas kasus penggunaan ini dijelaskan berdasarkan proses yang terjadi pada kasus penggunaan tersebut. Penjelasan tersebut dijelaskan sebagai berikut:

150 1. Proses Memilih Opsi Ekspor Hasil Deteksi Ketidaksesuaian

Gambar 3.23 Kelas diagram (class diagram) proses memilih opsi ekspor hasil deteksi ketidaksesuaian Kelas yang bertugas dalam proses ini adalah kelas “MainGui” dan kelas “SaveReportDialog”. Kelas “MainGui” sebagai perwujudan antarmuka utama kakas bantu tempat memilih opsi ekspor hasil deteksi ke bentuk laporan. Sedangkan, kelas “SaveReportDialog” adalah kelas antarmuka tempat untuk memilih lokasi penyimpanan dan format laporan hasil deteksi ketidaksesuaian. Kelas “SaveReportDialog” juga mewarisi kelas “javax.swing.JFileChooser”. Kelas juga ini dibantu oleh kelas “FileHandler” untuk mengecek jenis format laporan. Terdapat kelas “ReportHandler” sebagai objek yang dibuat ketika hasil deteksi ketidaksesuaian diekspor ke dalam bentuk laporan. Hubungan kelas-kelas ini ditunjukkan oleh Gambar 3.23. Kelas-kelas yang terlibat tidak jauh berbeda dengan penjelasan hubungan kelas-kelas sebelumnya. Sehingga, penjelasan atribut dan operasi kelas hanya menjelaskan bagian yang belum dijelaskan sebelumnya. Penjelasan atribut dan operasi tersebut dijabarkan oleh Tabel 3.24.

151 Tabel 3.24 Atribut dan operasi kelas (class) pada proses memilih opsi ekspor hasil deteksi ketidaksesuaian Kelas

Atribut/Operasi

Deskripsi

MainGui

clickSimpanHasilButton()

Bertugas menangani tindakan saat “simpanHasil” button ditekan/diberikan aksi dengan memanggil kelas “SaveReportDialog”.

SaveReportDialog

showSaveReportDialog()

Bertugas menampilkan jendela untuk memilih lokasi penyimpanan dan format laporan.

chooseSavedReportLocation()

Bertugas mendapatkan lokasi penyimpanan laporan.

chooseSavedReportFormat()

Bertugas mendapatkan format laporan.

inputSavedReportFileName()

Bertugas mendapatkan nama berkas laporan.

clickSaveButton()

Bertugas menyimpan lokasi penyimpanan laporan.

ReportHandler()

Bertugas sebagai constructor method untuk membuat objek penanda jika hasil deteksi ketidaksesuaian diekspor ke dalam bentuk laporan.

ReportHandler

2. Proses Mengekspor Hasil Deteksi dalam Bentuk Laporan Kelas-kelas yang terlibat dalam proses mengekspor hasil deteksi dalam bentuk laporan, antara lain kelas “UcdSdInconsistencyDetector”, kelas “ReportHandler”, kelas “UseCaseDescriptionDetectionResult”, kelas “TripletDetectionResult”, dan kelas “DocumentWriter”. Pertama, kelas “UcdSdInconsistencyDetector” memanggil kelas “ReportHandler” yang bertugas menangani pembuatan laporan hasil deteksi ketidaksesuaian. Kelas ini memproses hasil deteksi ketidaksesuaian dengan menyimpan ke dalam kelas model “UseCaseDescriptionDetectionResult”

152 dan “TripletDetectionResult”. Kelas model tersebut berisi kalimat alur kejadian dasar pada deskripsi kasus penggunaan (use case description) dan triplet yang telah dikelompokkan dalam bentuk daftar. Selanjutnya, kelas “DocumentWriter” sebagai kelas interface yang nantinya diimplementasikan oleh kelas “WordProcessorFormatWriter” dan “PdfFormatWriter” untuk mengubah hasil deteksi ke bentuk laporan dengan format “.doc”, “.docx”, atau “.pdf”. Hubungan kelas-kelas ini dapat ditunjukkan oleh Gambar 3.24, sedangkan atribut dan operasi masingmasing kelas tersebut dijelaskan oleh Tabel 3.25.

Gambar 3.24 Kelas diagram (class diagram) proses mengekspor hasil deteksi dalam bentuk laporan

153 Tabel 3.25 Atribut dan operasi kelas (class) pada proses mengekspor hasil deteksi dalam bentuk laporan Kelas

Atribut/Operasi

Deskripsi


reportHandler

Atribut dari kelas “ReportHandler”.

ReportHandler

isExportedToReport

Berisi nilai apakah hasil deteksi diekspor ke bentuk laporan.

reportFilePath

Berisi alamat berkas penyimpanan laporan.

ReportHandler()


setIsExportedToReport()

Bertugas menentukan nilai atribut “isExportedToReport”.

isExportedToReport()

Bertugas mendapatkan nilai atribut “isExportedToReport”.

setReportFilePath()

Bertugas menentukan nilai atribut “reportFilePath”.

getReportFilePath()

Bertugas mendapatkan nilai atribut “reportFilePath”.

exportToReport()

Bertugas mengekspor hasil deteksi ke berkas laporan.

useCaseName


detectedUseCaseDescription

Berisi list dari kalimat alur kejadian dasar pada deskripsi kasus penggunaan yang telah dideteksi.

setUseCaseName()


UseCaseDescriptionDetectionResult

154 Tabel 3.25 Atribut dan operasi kelas (class) pada proses mengekspor hasil deteksi dalam bentuk laporan (lanjutan) Kelas

DetectedUseCaseDescription

TripletDetectionResult

Atribut/Operasi

Deskripsi

getUseCaseName()


setDetectedUseCaseDescription()

Bertugas menentukan nilai atribut “detectedUseCaseDescription”.

getDetectedUseCaseDescription()

Bertugas mendapatkan nilai atribut “detectedUseCaseDescription”.

useCaseDescription

Berisi kalimat alur kejadian dasar pada deskripsi kasus penggunaan yang telah dideteksi.

label






setLabel()


getLabel()


useCaseName

Berisi nama kasus penggunaan.

detectedTriplet

Berisi list dari triplet yang telah dideteksi.

setUseCaseName()



Atribut/Operasi

Deskripsi

getUseCaseName()


setDetectedTriplet()

Bertugas menentukan nilai atribut “detectedTriplet”.

getDetectedTriplet()

Bertugas mendapatkan nilai atribut “detectedTriplet”.

sequenceDiagramTriplet

Berisi triplet yang telah dideteksi.

label


setSequenceDiagramTriplet()

Bertugas menentukan nilai atribut “sequenceDiagramTriplet”.

getSequenceDiagramTriplet()

Bertugas mendapatkan nilai atribut “sequenceDiagramTriplet”.

setLabel()


getLabel()


DocumentWriter

writeToDocument()

Bertugas sebagai definisi abstract method untuk menulis ke berkas dokumen.

WordProcessorFormatWriter

writeToDocument()

Bertugas mengimplementasikan abstract method untuk menulis berkas dokumen dalam format “.doc” atau “.docx”.

DetectedTriplet


Atribut/Operasi

Deskripsi

PdfFormatWriter

writeToDocument()

Bertugas mengimplementasikan abstract method untuk menulis berkas dokumen dalam format “.pdf”.

3.2.3.3

Diagram Kelas Keseluruhan

Secara keseluruhan, diagram kelas dari kakas bantu digambarkan dalam sebuah diagram paket (package diagram). Package diagram merupakan diagram yang dapat menjelaskan dekomposisi sistem ke dalam modul-modul sistem. Modul-modul sistem pada kakas bantu ini dikelompokkan berdasarkan perilaku kelas. Kelas yang memiliki perilaku yang mirip dimasukkan ke dalam modul yang sama. Kakas bantu yang dibuat terdiri dari satu modul utama yang terdiri dari delapan modul. Pemberian nama modul disesuaikan dengan konvensi nama package dari bahasa pemrograman Java.

Tabel 3.26 Modul-modul di dalam kakas bantu Modul

Deskripsi

id.ac.its.ucdsdinconsistencydetector

Modul utama kakas bantu. Modul ini terdiri dari kelas yang mewujudkan antarmuka kakas bantu. Modul ini berisi kelas-kelas yang menyimpan nilai konstan, seperti nilai ambang batas kemiripan kalimat dan penanda POS. Modul ini berisi kelas-kelas pengendali (control class) yang mengatur proses dari atau ke kelas lainnya, seperti proses dengan kelas model.

id.ac.its.ucdsdinconsistencydetector.constants

id.ac.its.ucdsdinconsistencydetector.control

157 Tabel 3.26 Modul-modul di dalam kakas bantu Kelas

Deskripsi

id.ac.its.ucdsdinconsistencydetector.interface id.ac.its.ucdsdinconsistencydetector.model id.ac.its.ucdsdinconsistencydetector.processor

Modul ini berisi kelas-kelas interface. Modul ini berisi kelas-kelas model.

id.ac.its.ucdsdinconsistencydetector.similarity.sentence id.ac.its.ucdsdinconsistencydetector.similarity.word id.ac.its.ucdsdinconsistencydetector.util

Modul ini berisi kelas-kelas yang memproses tugas tertentu, seperti ekstraksi dokumen rancangan. Modul ini berisi kelas-kelas yang mengimplentasikan perhitungan kemiripan kalimat. Modul ini berisi kelas-kelas yang mengimplentasikan perhitungan kemiripan kata. Modul ini berisi kelas-kelas yang membantu proses kelas lain, seperti part-of-speech-tagging, pembentukan matriks, atau perhitungan vektor.

Sesuai penjelasan sebelumnya, modul-modul tersebut terdiri dari kelas-kelas. Hubungan antara kelas-kelas dan modul-modul ditunjukkan oleh Gambar 3.25. Suatu modul membutuhkan modul lain dapat dilihat melalui hubungan “use”.

158

Gambar 3.25 Diagram paket (package diagram) kakas bantu

BAB IV IMPLEMENTASI SISTEM

Bab ini menjelaskan implementasi kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). Kakas bantu diimplementasikan dengan menggunakan bahasa pemrograman Java.

4.1 Lingkungan Implementasi Lingkungan pengembangan kakas bantu dilakukan dengan menggunakan komputer dengan spesifikasi Intel® Core™ i3-2330M CPU @ 2.20 GHz dengan memori sebesar 4 GB. Selain itu, terdapat perangkat lunak yang membantu selama proses pengembangan. Perangkat lunak tersebut antara lain: • Sistem operasi Linux Ubuntu 16.04.1 LTS (Xenial Xerus) 64-bit. • Kode editor NetBeans IDE 8.1 dengan Oracle Java Development Kit (JDK) versi 1.8.0_112 dan Apache Maven 3.0.5. • Pengelolaan versi kakas bantu dengan Git 2.7.4. • Penggunaan layanan BitBucket untuk menyimpan Git repository.

4.2 Detail Implementasi Kakas Bantu Detail implementasi kakas bantu dibagi berdasarkan perancangan antarmuka dan proses yang telah dijelaskan pada subbab perancangan sistem. Namun, tidak semua bagian implementasi tersebut dijelaskan. Implementasi antarmuka dijelaskan secara keseluruhan, sedangkan implementasi proses dijelaskan bagian yang penting saja. Bagian yang penting, misalnya implementasi menghitung kemiripan semantik antara kalimat alur kejadian dasar (basic flow) pada deskripsi kasus penggunaan (use case description) dan triplet. Penjelasan detail implementasi dari antarmuka dan proses kakas bantu dijelaskan melalui subbab berikut.

4.2.1 Implementasi Antarmuka Implementasi antarmuka kakas bantu dibuat dengan menggunakan pustaka Swing. Pustaka Swing adalah pustaka Java graphics API yang

159

160 menyediakan kumpulan komponen graphical user interface (GUI) yang dapat digunakan kembali, seperti tombol, label, kolom teks, dan frame untuk membangun aplikasi GUI. Implementasi antarmuka menggunakan pustaka ini dengan mudah bisa dibantu oleh kode editor NetBeans IDE melalui GUI builder. GUI builder adalah sebuah plugin yang digunakan untuk merancang antarmuka aplikasi dan melihat visualisasinya. Implementasi antarmuka kakas bantu terdiri dari:

4.2.1.1

Implementasi Antarmuka Utama

Hasil implementasi dari antarmuka utama kakas bantu ditunjukkan oleh Gambar 4.1. Gambar tersebut menunjukkan jendela utama yang terdiri dari tombol, kolom teks, dan komponen lain yang sesuai spesifikasi antarmuka pada Tabel 3.12. Jendela ini dalam implementasinya berupa sebuah kelas dengan nama “MainGui” yang mewarisi kelas “javax.swing.JFrame”. Dengan kelas “javax.swing.JFrame”, komponen GUI yang disediakan oleh Swing untuk membuat jendela (window) aplikasi dapat digunakan. Komponen tersebut, seperti tombol close, minimize, dan maximize, serta judul jendela yang sangat umum pada jendela sebuah aplikasi.

Gambar 4.1 Hasil implementasi antarmuka utama kakas bantu

161

4.2.1.2 Implementasi Jendela Masukan Berkas Dokumen Rancangan Hasil implementasi jendela masukan berkas dokumen rancangan ditunjukkan oleh Gambar 4.2. Gambar tersebut menunjukkan komponenkomponen yang umum dipakai saat memasukkan berkas. Implementasi jendela ini sesuai spesifikasi antarmuka pada Tabel 3.13. Jendela ini diimplentasikan oleh sebuah kelas dengan nama “FileChooserDialog” yang mewarisi kelas “javax.swing.JFileChooser”. Komponen-komponen untuk mengatur cara kerja pemilihan berkas disediakan oleh kelas “javax.swing.JFileChooser”. Komponen tersebut, seperti pemilihan lokasi berkas dan penyaringan format berkas.

Gambar 4.2 Hasil implementasi jendela “Masukan berkas dokumen rancangan”

4.2.1.3 Implementasi Antarmuka Ekspor Hasil Pemeriksaan ke dalam Laporan Antarmuka ekspor hasil pemeriksaan ke dalam laporan merupakan bagian antarmuka yang ada pada antarmuka utama kakas bantu. Hasil im-

162 plementasi antarmuka ini ditunjukkan oleh Gambar 4.3. Tampak kotak centang untuk memilih opsi ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan pada gambar. Kotak centang ini merupakan hasil penggunaan komponen “javax.swing.JCheckBox”. Tidak jauh berbeda dengan penjelasan implementasi antarmuka sebelumnya, hasil implementasi antarmuka ini mengacu pada spesifikasi antarmuka pada Tabel 3.14.

Gambar 4.3 Hasil implementasi antarmuka ekspor hasil pemeriksaan ke dalam laporan

4.2.1.4

Implementasi Jendela Simpan Hasil

Gambar 4.4 Hasil implementasi jendela ”Simpan hasil”

163 Hasil implementasi jendela simpan hasil ditunjukkan oleh Gambar 4.4. Gambar menunjukkan komponen antarmuka yang tidak jauh berbeda dengan komponen jendela “Masukan berkas dokumen rancangan”. Jendela ini juga mewarisi kelas “javax.swing.FileChooser” pada implementasinya. Namun, terdapat perbedaan di antara keduanya. Jendela ini berupa save dialog yang memanggil operasi “showSaveDialog()”, sedangkan jendela “Masukan berkas dokumen rancangan” berupa open dialog yang memanggil operasi “showOpenDialog()”. Kedua operasi tersebut ada pada kelas “javax.swing.FileChooser”. Implementasi jendela ini mengacu pada spesifikasi antarmuka pada Tabel 3.15.

4.2.2 Implementasi Proses Sesuai penjelasan sebelumnya, detail implementasi proses yang ada di dalam kakas bantu tidak dijelaskan secara keseluruhan. Bagian implementasi proses yang penting saja dijelaskan. Implementasi proses tersebut antara lain:

4.2.2.1 Implementasi Proses Mengekstraksi Dokumen Rancangan Dokumen rancangan yang telah dimasukkan ke dalam kakas bantu diekstraksi isinya saat proses deteksi ketidaksesuaian dimulai. Proses deteksi ketidaksesuaian ditunjukkan oleh fungsi doInconsistencyDetection pada Kode Sumber 4.1.

Kode Sumber 4.1 Potongan kode fungsi mendeteksi ketidaksesuaian 1 2 3 4 5 6

public UcdSdDetectionResult doInconsistencyDetection( ,→ String designFilePath, String reportFilePath, boolean isExportedToReport) throws ,→ ParserConfigurationException, SAXException, IOException, FileNotFoundException ,→ { XmiParser xmiParser = new XmiParser(); xmiParser.extractDesignFile(designFilePath);

164 Fungsi doInconsistencyDetection memiliki parameter designFilePath yang berisi alamat berkas dokumen rancangan. Fungsi ini pertama kali memanggil fungsi extractDesignFile pada kelas XmiParser untuk mengekstraksi dokumen rancangan (baris ke-5 dan ke-6). Fungsi extractDesignFile melakukan ekstraksi dokumen rancangan dengan mengambil alamat berkas dokumen rancangan tersebut. Fungsi ini ditunjukkan oleh Kode Sumber 4.2.

Kode Sumber 4.2 Potongan kode fungsi mengekstraksi dokumen rancangan 1 2 3 4 5 6 7 8

public void extractDesignFile(String designFilePath) ,→ throws ParserConfigurationException, SAXException, IOException { File designFile = new File(designFilePath); SAXParserFactory factory = SAXParserFactory. ,→ newInstance(); SAXParser saxParser = factory.newSAXParser(); saxParser.parse(designFile, xmiParsingHandler);

Ekstraksi dokumen rancangan dalam format “.xmi” dibantu oleh SAX (the Simple API for XML). SAX merupakan salah satu pustaka untuk memparsing dokumen XML. Pustaka ini mengambil elemen dokumen XML dengan membaca berkas dari atas ke bawah. Proses ekstraksi elemen dokumen ditunjukkan oleh fungsi parse pada baris ke-8. Fungsi ini mengimplementasikan API (Application Programming Interface) yang disediakan oleh SAX. Implementasi tersebut ditunjukkan oleh Kode Sumber 4.3.

Kode Sumber 4.3 Potongan kode API dari SAX 1 2 3 4 5 6

public void startElement(String uri, String localName, ,→ String queryName, Attributes attributes) { if (queryName.equalsIgnoreCase(XmiElement. ,→ PACKAGED_ELEMENT)) { packagedElement = new PackagedElement(); String packagedType = attributes.getValue( ,→ XmiAttribute.XMI_TYPE); String packagedName = attributes.getValue( ,→ XmiAttribute.NAME_ATTRIBUTE);

165 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

packagedElement.setType(packagedType); packagedElement.setName(packagedName); } else if (queryName.equalsIgnoreCase(XmiElement. ,→ DOCUMENTATION_ELEMENT)) { ... } else if ... } @Override public void endElement(String uri, String localName, ,→ String queryName) { if (queryName.equalsIgnoreCase(XmiElement. ,→ PACKAGED_ELEMENT)) { packagedElementList.add(packagedElement); } else if (queryName.equalsIgnoreCase(XmiElement. ,→ DOCUMENTATION_ELEMENT)) { ... } else if ... }

Fungsi startElement pada baris ke-1 untuk memberikan notifikasi dimulainya ekstraksi elemen yang ada pada dokumen rancangan. Baris ke-2 memulai ekstraksi elemen packagedElement. Informasi yang diambil dari elemen ini adalah nilai atribut xmi:type (baris ke-5) dan name (baris ke-6). Setiap informasi tersebut disimpan ke dalam kelas model PackagedElement yang ada pada baris ke-3. Ekstraksi dilanjutkan oleh elemen-elemen yang telah dijabarkan pada Tabel 3.16. Fungsi endElement pada baris ke-15 berfungsi sebaliknya sebagai notifikasi berhentinya ekstraksi elemen dokumen rancangan. Mengambil contoh yang sama, elemen packagedElement yang telah disimpan menjadi objek-objek PackagedElement dimasukkan ke dalam list packagedElementList (baris ke-17). Hal yang sama juga diberlakukan untuk elemen-elemen yang telah dijelaskan sebelumnya.

4.2.2.2 Implementasi Proses Mendeteksi Ketidaksesuaian Hasil ekstraksi elemen dokumen rancangan yang telah disimpan sebelumnya dikelompokkan sebelum dideteksi ketidaksesuaiannya. Pengelompokkan ini dilakukan karena hasil ekstraksi masih berupa elemen-elemen yang terpisah. Elemen-elemen yang terpisah tersebut dikelompok-

166 kan ke dalam kasus penggunaan (use case), deskripsi kasus penggunaan (use case description), dan diagram urutan (sequence diagram). Sebagai contoh pengelompokan kasus penggunaan, pengelompokan ini mengelompokkan nama kasus penggunaan. Nama kasus penggunaan didapatkan dari list packagedElementList. Proses ini dtunjukkan oleh Kode Sumber 4.4.

Kode Sumber 4.4 Potongan kode fungsi mengelompokkan nama kasus penggunaan (use case) 1

List<String> packagedElementList = new ArrayList<>() ,→ ; List<String> useCaseNameList = new ArrayList<>(); int packagedElementListLength = xmiParsingHandler. ,→ getPackagedList().size();

2 3 4 5

for (int i = 0; i < packagedElementListLength; i++) ,→ { packagedElementList.add(xmiParsingHandler. ,→ getPackagedList().get(i).toString()); }

6 7 8 9

String[] packagedElement = new String[ ,→ packagedElementList.size()]; packagedElement = packagedElementList.toArray( ,→ packagedElement);

10 11 12 13 14 15 16 17 18 19 20 21

for (String string : packagedElement) { String[] tokens = string.split("-"); String firstToken = tokens[0]; String secondToken = tokens[1]; if (XmiParserUtil.isUseCaseName(firstToken)) { useCaseNameList.add(secondToken); } } ...

Baris ke-2 dari potongan kode tersebut menunjukkan pembuatan list useCaseNameList untuk menampung nama kasus penggunaan dan baris ke-6 pengambilan list packagedElementList. Selanjutnya, pengelompokan nama kasus penggunaan ke dalam useCaseNameList dengan

167 mengecek apakah tipe dari elemen list packagedElementList adalah sebuah use case (baris ke-17). Pengelompokan ini juga dilakukan untuk deskripsi kasus penggunaan dan diagram urutan. Pengelompokan deskripsi kasus penggunaan dengan mengelompokkan nama kasus penggunaan dan kalimat deskripsinya. Pengelompokan diagram urutan dengan mengelompokkan judul diagram, kelas (lifeline), dan method-nya. Ketika pengelompokan selesai dilakukan, implementasi proses ini dapat dilanjutkan dengan memulai deteksi ketidaksesuaian. Deteksi dimulai dengan mengambil satu kasus penggunaan. Bagian ini dapat dilihat pada Kode Sumber 4.5 baris ke-2. Deskripsi kasus penggunaan yang berisi kalimat alur kejadian dasar (basic flow) bisa diambil (baris ke-3). Kemudian, memecah deskripsi tersebut untuk mendapatkan kalimat-kalimatnya (baris ke-4). Pemecahan ini dilakukan oleh fungsi getSentencesFromParagraph yang dibantu oleh pustaka Stanford EnglishTokenizer [12]. Setelah mendapatkan kalimat-kalimat tunggal dari deskripsi kasus penggunaan, kalimat-kalimat tersebut dikelompokkan kembali berdasarkan kasus penggunaan saat ini (baris ke-7).

Kode Sumber 4.5 Potongan kode fungsi mendeteksi ketidaksesuaian 1 2

3

4

5 6 7 8 9 10 11 12

for (int i = 0; i < useCaseListLength; i++) { String useCaseName = xmiParser. ,→ getUseCaseDescription().get(i). ,→ getUseCaseName(); String useCaseDescription = xmiParser. ,→ getUseCaseDescription().get(i). ,→ getUseCaseFlow(); List<String> flowOfEvents = SentenceUtil. ,→ getSentencesFromParagraph( ,→ useCaseDescription); for (String flowOfEvent : flowOfEvents) { this.groupUcfByUseCase(i, flowOfEvent); } String sequenceDiagramTitle = xmiParser. ,→ getSequenceDiagram().get(i).getTitle(); if (sequenceDiagramTitle.equals(useCaseName)) {

168 13

List<SequenceDiagramMethod> ,→ sequenceDiagramMethods = xmiParser. ,→ getSequenceDiagram().get(i). ,→ getListOfMethod(); ...

14 15 16

for (SequenceDiagramMethod ,→ sequenceDiagramMethod : ,→ sequenceDiagramMethods) { ...

17 18 19

String senderClassName = ,→ SequenceDiagramUtil. ,→ getSenderClass(senderClassId, sequenceDiagramFragments, ,→ sequenceDiagramClasses); String methodName = ... String receiverClassName = ...

20 21 22 23 24

this.groupTripletBySequenceDiagram(i, ,→ senderClassName, methodName, ,→ receiverClassName);

25 26 27

} } else { System.out.println("Diagram urutan " + ,→ sequenceDiagramTitle + " tidak ,→ ditemukan."); }

28 29 30

31

ucdSdDetectionReport = this.calculateUcfTriplet( ,→ useCaseName, this.getUcfByUseCase().get(i ,→ ), this.getTripletBySequenceDiagram().get ,→ (i)); }

Judul diagram urutan diambil (baris ke-10) dan dicek apakah sama dengan kasus penggunaan saat ini (baris ke-12). Pengecekan bertujuan untuk menemukan pasangan kasus penggunaan dengan diagram urutannya. Apabila tidak ditemukan, sebuah pesan yang ditampilkan (baris ke-27). Apabila pasangan diagram urutan ditemukan, mengelompokkan triplet dari diagram urutan tersebut. Pengelompokan dilakukan dengan mengam-

169 bil method-method diagram urutan saat ini dari list sequenceDiagramMethods dan mencari kelas pengirim dan penerima method (baris ke-13 sampai dengan baris ke-22) sesuai penjelasan proses ini pada subbab perancangan proses kakas bantu. Proses ini dilanjutkan dengan menghitung kemiripan kalimat alur kejadian dasar kasus penggunaan yang telah dikelompokkan tadi dengan triplet oleh fungsi calculateUcfTriplet (baris ke-30). Fungsi calculateUcfTriplet merupakan fungsi untuk menghitung kesesuaian antara kalimat alur kejadian dasar penggunaan dengan triplet yang nantinya menggunakan pendekatan kemiripan semantik kalimat. Namun, fungsi ini lebih banyak bertugas melakukan pre-processing triplet sebelum dihitung kesesuaiannya dan mengatur alur deteksi pasangan kalimat deskripsi kasus penggunaan dan triplet. Potongan kode preprocessing triplet ditunjukkan oleh Kode Sumber 4.6. Pre-processing pada konteks ini adalah mengubah triplet menjadi kalimat. Hal ini dilakukan karena nantinya triplet dibandingkan dengan kalimat alur kejadian dasar kasus penggunaan untuk mendapatkan nilai kemiripan semantik kalimat.

Kode Sumber 4.6 Potongan kode pre-processing triplet 1 2 3 4 5 6 7 8 9 10 11 12 13

for (int i = 0; i < sequenceDiagramTriplet.size(); i ,→ ++) { Triplet sdTriplet = sequenceDiagramTriplet.get(i ,→ ); String senderClass = sdTriplet.getFirstValue(); String method = sdTriplet.getSecondValue(); String receiverClass = sdTriplet.getThirdValue() ,→ ; String[] senderClassTokens = SequenceDiagramUtil ,→ .splitCamelCaseToWords(senderClass); String senderClassName = ""; for (int j = 0; j < senderClassTokens.length; j ,→ ++) { if (TokenUtil.isAllUppercase( ,→ senderClassTokens[j])) { if (j == 0) { senderClassName += "The " + ,→ senderClassTokens[j]; } else {

170 14

senderClassName += senderClassTokens ,→ [j];

15 16 17 18

} } else { if (j == 0) { senderClassName += "The " + ,→ senderClassTokens[j]. ,→ toLowerCase(); } else { senderClassName += ,→ senderClassTokens[j]. ,→ toLowerCase(); } } ...

19 20

21 22 23 24 25 26 27 28

} String methodName = ""; if (method != null && !method.isEmpty()) { String[] methodTokens = SequenceDiagramUtil. ,→ splitCamelCaseToWords(method);

29 30

for (int j = 0; j < methodTokens.length; j ,→ ++) { if (TokenUtil.isAllUppercase( ,→ methodTokens[j])) { methodName += methodTokens[j]; } else { methodName += methodTokens[j]. ,→ toLowerCase(); } ... }

31 32 33 34 35 36 37 38 39 40

41 42

} String[] receiverClassTokens = ,→ SequenceDiagramUtil.splitCamelCaseToWords ,→ (receiverClass); String receiverClassName = ""; for (int j = 0; j < receiverClassTokens.length; ,→ j++) {

171 43

if (TokenUtil.isAllUppercase( ,→ receiverClassTokens[j])) { receiverClassName += receiverClassTokens ,→ [j]; } else { receiverClassName += receiverClassTokens ,→ [j].toLowerCase(); } ...

44 45 46 47 48 49 50 51

} String sdTripletString = senderClassName.concat( ,→ " ").concat(methodName).concat(" "). ,→ concat(receiverClassName).concat(".");

Pre-processing dimulai dengan mengambil nama kelas pengirim, nama method, dan nama kelas penerima (baris ke-3 sampai dengan baris ke5). Kemudian, menambahkan artikel “The” sebelum nama kelas pengirim (baris ke-12). Lower-casing nama kelas pengirim, nama method, dan nama kelas penerima tidak dilakukan apabila nama disusun oleh gabungan huruf kapital (baris ke-10, ke-31, dan ke-43). Kata kerja pada nama method perlu diubah ke bentuk kata kerja bentuk orang ketiga tunggal dengan menjamakkan kata kerjanya. Penjamakan dibantu oleh fungsi pluralize dari pustaka RiTa [31]. Terakhir, menggabungkan nama kelas pengirim, nama method, dan nama kelas penerima yang telah dilakukan preprocessing tadi agar menjadi kalimat (baris ke-51). Proses ini dilanjutkan dengan menghitung kemiripan kalimat antara kalimat alur kejadian dasar kasus penggunaan dengan triplet yang telah diubah menjadi kalimat.

4.2.2.3 Implementasi Proses Menghitung Kemiripan Kalimat Alur Kejadian Dasar (Basic Flow) dan Triplet Perhitungan kemiripan kalimat alur kejadian dasar pada deskripsi kasus penggunaan (use case description) dengan triplet menggunakan pendekatan kemiripan semantik kalimat. Pendekatan yang digunakan adalah metode yang diajukan oleh Lee [14]. Implementasi perhitungan dengan metode tersebut diawali dengan pre-processing kalimat yang ditunjukkan oleh Kode Sumber 4.7. Pre-processing dilakukan hanya untuk menghilangkan tanda baca yang ada pada kedua kalimat. Proses ini di-

172 tunjukkan oleh kode pada baris ke-3 dan ke-4. Penghilangan tanda baca dibantu oleh fungsi stripPunctuation dari pustaka RiTa.

Kode Sumber 4.7 Potongan kode pre-processing kalimat 1 2 3

4

@Override public double similarity(String firstSentence, String ,→ secondSentence) { String removedPunctuationFirstSentence = ,→ SentenceUtil.removePunctuation(firstSentence) ,→ ; String removedPunctuationSecondSentence = ,→ SentenceUtil.removePunctuation(secondSentence ,→ );

Kemudian, part-of-speech (POS) tagging dari kedua kalimat yang telah melalui pre-processing. POS tagging kalimat ditunjukkan oleh Kode Sumber 4.8 melalui fungsi doTagging. Fungsi ini melakukan POS tagging kalimat dengan menggunakan pustaka NLP4J [32]. Token yang berisi kata dan penanda POS dari kalimat pertama dan kedua didapatkan melalui kode baris ke-1 dan ke-2. Sebelum token tersebut dikelompokkan ke dalam kata benda dan kata kerja melalui penanda POS yang telah didapatkan, kata-kata dalam kedua kalimat harus diubah ke bentuk dasarnya melalui lemmatization. Lemmatization terjadi pada kode baris ke-3 dan ke-4 dengan memanggil fungsi lemmatize. Fungsi ini menjalankan lemmatize dengan bantuan pustaka Stanford CoreNLP.

Kode Sumber 4.8 Potongan kode part-of-speech tagging dan lemmatization kalimat 1

2

3

4

String[] taggedFirstSentenceTokens = SentenceUtil. ,→ doTagging(removedPunctuationFirstSentence. ,→ concat(".")).split(" "); String[] taggedSecondSentenceTokens = SentenceUtil. ,→ doTagging(removedPunctuationSecondSentence. ,→ concat(".")).split(" "); List<String> lemmatizedFirstSentenceTokens = ,→ SentenceUtil.lemmatize( ,→ removedPunctuationFirstSentence.concat(".")); List<String> lemmatizedSecondSentenceTokens = ,→ SentenceUtil.lemmatize(

173 ,→ removedPunctuationSecondSentence.concat(".")) ,→ ;

Hasil POS tagging dan lemmatization yang telah dilakukan digunakan untuk mengelompokkan kata benda dan kata kerja. Sebagai contoh, pengelompokan kata benda dan kata kerja pada kalimat pertama. Pengelompokan ditunjukkan oleh Kode Sumber 4.9.

Kode Sumber 4.9 Potongan kode pengelompokan kata benda dan kata kerja 1 2 3 4 5 6

List<String> nounSetFirstSentence = new ArrayList ,→ <>(); List<String> verbSetFirstSentence = new ArrayList ,→ <>(); for (int i = 0; i < taggedFirstSentenceTokens.length ,→ - 1; i++) { String firstSentencePosTag = PosUtil.getPOSTag( ,→ taggedFirstSentenceTokens[i]); String firstSentencePosWord = ,→ lemmatizedFirstSentenceTokens.get(i). ,→ toLowerCase();

7 8

if ((PosUtil.isSingularNoun(firstSentencePosTag) ,→ || PosUtil.isPluralNoun( ,→ firstSentencePosTag) || ...) { if (WordUtil.isNoun(firstSentencePosWord)) { nounSetFirstSentence.add( ,→ firstSentencePosWord); } } else if (PosUtil.isBaseFormVerb( ,→ firstSentencePosTag) || PosUtil. ,→ isPastParticiple(firstSentencePosTag) || ,→ PosUtil.isThirdPersonSingularPersonVerb( ,→ firstSentencePosTag) || ...) { if (WordUtil.isVerb(firstSentencePosWord)) { verbSetFirstSentence.add( ,→ firstSentencePosWord); } }

9 10 11 12

13 14 15 16 17

}

174 Terdapat list nounSetFirstSentence (baris ke-1) dan verbSetFirstSentence (baris ke-2) untuk menampung kata benda dan kata kerja kalimat pertama. Pengelompokan dimulai dengan mengambil penanda POS setiap token hasil POS tagging kalimat pertama (baris ke-5) dan kata dasarnya hasil lemmatization yang telah di-lower-casing (baris ke-6). Setelah itu, mengecek apakah penanda tersebut termasuk kata benda atau kata kerja sesuai kode baris ke-8 dan ke-12. Penanda kata benda diatur oleh fungsi isSingularNoun dan seterusnya, sedangkan kata kerja diatur oleh fungsi isBaseFormVerb dan seterusnya. Kedua fungsi tersebut mengacu pada penanda POS Tabel 2.4. Misal, penanda dari token saat ini adalah kata benda. Kata dasar dari token tersebut ditampung ke dalam list nounSetFirstSentence (baris ke-10). Sebelum ditampung ke dalam list, kata dasar tersebut harus dicek apakah termasuk kata benda pada WordNet (baris ke-9) untuk memastikan kata tersebut adalah kata benda dan bukan stop word. Proses ini dilanjutkan oleh token berikutnya. Hal yang sama juga dilakukan untuk kalimat kedua. Kata benda dan kata kerja dari kedua kalimat yang telah ditampung kemudian digunakan untuk menghitung kemiripan kata. Penghitungan kemiripan kata dilakukan dengan membandingkan kata benda dari masingmasing kalimat dengan gabungan kata benda dari kedua kalimat dan kata kerja dari masing-masing kalimat dengan gabungan kata kerja dari kedua kalimat. Gabungan tersebut disebut dengan ruang semantik kata benda dan ruang semantik kata kerja. Sebagai contoh, perhitungan kemiripan ruang semantik kata benda dengan kata benda kalimat pertama. Perhitungan ini dapat dilihat pada Kode Sumber 4.10. Perhitungan diawali dengan pembentukan ruang semantik kata benda dengan menggabungkan kata benda kedua kalimat melalui fungsi mergeTwoArrayStringWithoutDuplicate (baris ke-1). Fungsi ini menggabungkan dua buah array of string tanpa adanya duplikasi elemen. Kemudian, membentuk matriks yang setiap barisnya berisi nilai-nilai kemiripan antara kata ruang semantik kata benda dengan kata benda kalimat pertama (baris ke-2).

Kode Sumber 4.10 Potongan kode perhitungan kemiripan ruang semantik kata benda dengan kata benda kalimat pertama 1

String[] nounSemanticSpace = TokenUtil. ,→ mergeTwoArrayStringWithoutDuplicate( ,→ nounSetFirstSentence.toArray(new String[0]), ,→ nounSetSecondSentence.toArray(new String[0]))

175

2 3 4 5

,→ ; List> firstNounSemanticVector = Matrix. ,→ create(nounSetFirstSentence.size()); for (int i = 0; i < nounSetFirstSentence.size(); i ,→ ++) { List wordSimilarityScore = new ArrayList ,→ <>();

6 7 8 9 10

for (String word : nounSemanticSpace) { double score; if (nounSetFirstSentence.get(i).equals(word) ,→ ) { score = 1.0; } else { score = linWordSimilarity.similarity( ,→ nounSetFirstSentence.get(i), word ,→ , "n"); }

11 12 13

14 15 16 17 18 19 20

wordSimilarityScore.add(score); } Matrix.addRow(firstNounSemanticVector, i, ,→ wordSimilarityScore); }

Kemiripan kata dihitung dengan membandingkan setiap kata benda kalimat pertama dengan kata pada ruang semantik kata benda (dimulai dari baris ke-4 hingga baris ke-20). Terdapat list wordSimilarityScore yang menampung nilai kemiripan setiap baris pada matriks yang telah dibuat tadi (baris ke-5). Jika kata benda dengan kata pada ruang semantik kata benda sama maka diberikan nilai kemiripan 1,0 (baris ke-10). Jika tidak maka menghitung nilai kemiripan semantik kata (baris ke-13). Perhitungan semantik kata dibahas pada subbab berikutnya. Setiap nilai kemiripan ditampung pada list wordSimilarityScore untuk selanjutnya dimasukkan ke dalam matriks (baris ke-19). Proses yang sama juga dilakukan untuk kata benda dan kata kerja kalimat kedua. Selanjutnya, mendapatkan nilai tertinggi dari masing-masing kolom

176 pada matriks yang telah didapatkan pada proses sebelumnya. Nilai tersebut menjadi elemen dari vektor kata benda dan vektor kata kerja. Sebagai contoh, proses mendapatkan vektor kata benda kalimat pertama yang ditunjukkan oleh Kode Sumber 4.11.

Kode Sumber 4.11 Potongan kode mendapatkan vektor kata benda kalimat pertama 1 2 3 4

for (int i = 0; i < nounSemanticSpace.length; i ,→ ++) { List columnList = new ArrayList<>(); for (int j = 0; j < firstNounSemanticVector. ,→ size(); j++) { List rowList = ,→ firstNounSemanticVector.get(j); columnList.add(rowList.get(i)); }

5 6 7 8 9 10 11

double maxColumnWeight = Matrix. ,→ getMaxColumnValue(columnList); firstNounWeightVector.add(maxColumnWeight); }

Terdapat sebuah list columnList (baris ke-2) untuk menyimpan nilai elemen setiap baris matriks. Untuk setiap baris matriks kata benda kalimat pertama, elemen diambil (baris ke-5) dan dimasukkan ke dalam columnList (baris ke-6). Nilai yang ada pada columnList masih berisi semua nilai elemen setiap baris matriks. Oleh sebab itu, fungsi getMaxColumnValue dijalankan untuk mendapatkan nilai tertinggi dari setiap baris matriks tersebut (baris ke-9). Setiap nilai tertinggi ini disimpan ke dalam list firstNounWeightVector sebagai vektor kata benda kalimat pertama (baris ke-10). Proses yang sama juga diberlakukan untuk kalimat kedua. Vektor kata benda dan kata kerja dari kedua kalimat yang telah didapatkan digunakan untuk menghitung nilai cosine similarity. Perhitungan cosine similarity diterapkan untuk vektor kata benda kalimat pertama dengan vektor kata benda kalimat kedua dan vektor kata kerja kalimat pertama dan vektor kata kerja kalimat kedua. Sehingga, perhitungan menghasilkan dua nilai cosine similarity. Kode Sumber 4.12 menunjukkan perhitungan cosine similarity untuk kata benda. Terdapat vektor kata benda

177 kalimat pertama firstNounWeightVector dan vektor kata benda kalimat kedua secondNounWeightVector. Fungsi dot untuk menghitung dot product vektor dan magnitude untuk mendapatkan panjang vektor.

Kode Sumber 4.12 Potongan kode menghitung nilai cosine similarity kata benda 1

nounCosineAngle = (Vector.dot( ,→ firstNounWeightVector, ,→ secondNounWeightVector)) / (Vector. ,→ magnitude(firstNounWeightVector) * Vector ,→ .magnitude(secondNounWeightVector));

Hal yang sama juga dilakukan untuk perhitungan nilai cosine similarity kata kerja. Terakhir, nilai cosine similarity kata benda dan kata kerja yang telah didapatkan digunakan untuk menghitung nilai akhir kemiripan semantik kalimat sesuai Persamaan 2.2. Perhitungan ditunjukkan oleh Kode Sumber 4.13.

Kode Sumber 4.13 Potongan kode menghitung nilai akhir kemiripan semantik kalimat 1

return SimilarityConstant. ,→ MING_CHE_LEE_BALANCE_COEFICIENT * ( ,→ nounCosineAngle * nounCosineAngle) + ((1.0 ,→ SimilarityConstant. ,→ MING_CHE_LEE_BALANCE_COEFICIENT) * ( ,→ verbCosineAngle * verbCosineAngle));

nounCosineAngle dan verbCosineAngle masing-masing adalah ni-

lai cosine similarity kata benda dan kata kerja. Terdapat nilai konstan MING_CHE_LEE_BALANCE_COEFICIENT untuk menyeimbangkan bobot nounCosineAngle dan verbCosineAngle. Nilai 0,65 dipilih sebagai

nilai konstan tersebut.

4.2.2.4 Implementasi Proses Menghitung Kemiripan Kata Perhitungan kemiripan kata yang diimplementasikan adalah kemiripan semantik kata menggunakan metode yang diajukan oleh Lin [26]. Perhitungan menggunakan WordNet sebagai sumber hubungan semantik antar kata dan pustaka Slib [30] untuk menerapkan metrik Lin. Versi

178 WordNet yang digunakan adalah WordNet 3.1. Implementasi metrik Lin untuk perhitungan kemiripan semantik kata dengan pustaka Slib ditunjukkan oleh Kode Sumber 4.14. Konteks perhitungan pada potongan kode tersebut adalah menghitung kemiripan antar kata benda. Terdapat fungsi similarity dengan parameter firstWord dan secondWord masinmasing adalah kata pertama dan kata kedua yang dihitung kemiripannya dan posTag sebagai penanda POS kata (kata benda, kata kerja, kata sifat, atau kata keterangan).

Kode Sumber 4.14 Potongan kode fungsi menghitung kemiripan semantik kata dengan metrik Lin 1 2 3 4 5 6 7 8 9 10 11 12 13

14 15 16 17 18 19 20

@Override public double similarity(String firstWord, String ,→ secondWord, String posTag) { double similarityScore = 0.0; try { URIFactory factory = URIFactoryMemory. ,→ getSingleton(); URI guri = factory.getURI("http://graph/wordnet/ ,→ "); G wordnet = new GraphMemory(guri); GraphLoader_Wordnet loader = new ,→ GraphLoader_Wordnet(); if (posTag.equals(PosTag.LOWERCASE_NOUN)) { GDataConf dataNoun = new GDataConf(GFormat. ,→ WORDNET_DATA, FilePath.WORDNET_PATH + ,→ "data.noun"); loader.populate(dataNoun, wordnet); GAction addRoot = new GAction((GActionType. ,→ REROOTING)); GraphActionExecutor.applyAction(addRoot, ,→ wordnet); String indexNoun = FilePath.WORDNET_PATH + " ,→ index.noun";

179 21 22

23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

IndexerWordNetBasic indexerWordNetNoun = new ,→ IndexerWordNetBasic(factory, wordnet ,→ , indexNoun); Set firstNounWords = indexerWordNetNoun ,→ .get(firstWord); Set secondNounWords = ,→ indexerWordNetNoun.get(secondWord); URI firstNounWord = firstNounWords.iterator ,→ ().next(); URI secondNounWord = secondNounWords. ,→ iterator().next(); ICconf iconf = new IC_Conf_Topo(SMConstants. ,→ FLAG_ICI_SANCHEZ_2011); SMconf measureConf = new SMconf(SMConstants. ,→ FLAG_SIM_PAIRWISE_DAG_NODE_LIN_1998); measureConf.setICconf(iconf); SM_Engine engine = new SM_Engine(wordnet); similarityScore = engine.compare(measureConf ,→ , firstNounWord, secondNounWord); } else if (posTag.equals(PosTag.LOWERCASE_VERB)) ,→ { ...

Perhitungan dimulai dengan mengawali nilai kemiripan kata similarityScore dengan 0 (baris ke-3). Kemudian, membuat sebuah graph sesuai kode baris ke-6 sampai dengan baris ke-8. Graph yang dibuat digunakan untuk memuat data WordNet. Proses ini ditunjukkan oleh kode baris ke-10 sampai dengan baris ke-15. Terdapat pengecekan apakah penanda kata yang dimaksud adalah kata benda pada baris ke-12. Data yang dimuat ke dalam graph dalam konteks ini adalah berkas data.noun yang ada di dalam directory WordNet (baris ke-13). Graph yang telah memuat data kata benda dari WordNet di-rooting. Proses ini menghasilkan rooted graph, sebuah graph di mana satu node diberikan label tertentu untuk membedakan dengan node lainnya, yang dibutuhkan untuk membanding-

180 kan synsets-synsets nantinya. Setelah itu, membuat sebuah indeks untuk memetakan kata benda ke vertex graph yang telah di-rooting tadi. Proses ini ditunjukkan oleh kode baris ke-20 dan ke-22 yang memuat berkas index.noun yang juga berada pada directory WordNet. Indeks yang telah dibuat digunakan untuk mengambil URI (uniform resource identifier) dari kata benda pertama dan kata benda kedua (baris ke-24 dan ke-25). Setiap URI yang didapatkan dapat diasosiasikan dengan kata benda yang sama (synsets-nya). Sehingga, kata benda yang berasosiasi dibentuk ke dalam satu URI (baris ke-27 dan ke28). Kode baris ke-31 menunjukkan perhitungan kemiripan semantik kata dengan metrik yang dipilih, yaitu Lin. Metrik ini digunakan untuk menghitung kemiripan antara dua kata berdasarkan information content (IC). Model IC juga diatur untuk menggunakan metrik ini. Sánchez et al. adalah model IC yang digunakan (baris ke-30). Terakhir, menghitung nilai kemiripan semantik kedua kata sesuai kode baris ke-36 dan menyimpan hasilnya ke dalam similarityScore. Proses yang sama juga berlaku untuk menghitung kemiripan kata kerja, kata sifat, dan kata keterangan.

4.2.2.5

Implementasi Proses Mengekspor Hasil Deteksi dalam Bentuk Laporan

Saat menghitung kemiripan semantik antara kalimat alur kejadian dasar (basic flow) dan triplet, setiap nilai kemiripan baik yang memenuhi maupun tidak memenuhi ambang batas (threshold) menentukan hasil deteksi ketidaksesuaian. Hasil deteksi ketidaksesuaian menyimpan informasi nama kasus penggunaan (use csase), kalimat alur kejadian dasar kasus penggunaan, triplet, dan label kesesuaian. Hasil tersebut disimpan dalam bentuk list rowDetectionResults baris ke-1 Kode Sumber 4.15. Baris tersebut juga menunjukkan kelas RowDetectionResults yang mana merupakan kelas model yang menyimpan informasi hasil deteksi ketidaksesuaian yang terdiri dari nama kasus penggunaan, kalimat alur kejadian dasar kasus penggunaan, triplet, dan label kesesuaian.

Kode Sumber 4.15 Potongan kode menyimpan hasil deteksi ketidaksesuaian 1 2

List rowDetectionResults = new ,→ ArrayList<>();

181 3 4 5 6

7 8 9 10 11 12 13 14

15 16 17

18

19 20

for (int i = 0; i < flowOfEvents.size(); i++) { for (int j = 0; j < sdTripletLists.size(); j++) ,→ { RowDetectionResult resultData = new ,→ RowDetectionResult(); MingCheLeeSentenceSemanticSimilarity ,→ mingCheLeeSentenceSemanticSimilarity ,→ = new ,→ MingCheLeeSentenceSemanticSimilarity ,→ (); ... rowDetectionResults.add(resultData); } } if (reportHandler.isIsExportedToReport()) { reportHandler.exportToReport(rowDetectionResults ,→ , tripletList, reportHandler. ,→ getReportFilePath()); } UseCaseDescriptionDetectionResult ucdResult = ,→ DetectionResultUtil.getUcdDetectionResult( ,→ rowDetectionResults); TripletDetectionResult tripletResult = ,→ DetectionResultUtil.getTripletDetectionResult ,→ (rowDetectionResults, tripletList); UcdSdDetectionResult ucdSdDetectionResult = new ,→ UcdSdDetectionResult(ucdResult, tripletResult ,→ );

Baris ke-3 sampai dengan baris ke-11 adalah proses menghitung kemiripan pasangan kalimat alur kejadian dasar dengan triplet sesuai penjelasan aturan perhitungan pasangan kalimat alur kejadian dasar dengan triplet yang telah pada subbab perancangan proses. Kemudian, baris ke-17 dan ke-18 adalah proses mendapatkan hasil deteksi ketidaksesuaian dalam bentuk daftar kalimat alur kejadian dasar kasus penggunaan dan triplet dengan memproses hasil yang disimpan pada rowDetectionResults. Pembuatan objek UcdSdDetectionResult untuk menampung daf-

182 tar hasil deteksi ketidaksesuaian tadi (20). Informasi dari objek inilah yang nantinya ditampilkan pada antarmuka utama kakas bantu. Melompat balik ke baris 13, baris tersebut menunjukkan apakah hasil deteksi ketidaksesuaian dieskpor ke bentuk laporan. Apabila iya, fungsi exportToReport pada kelas ReportHandler dijalankan. Fungsi exportToReport berfungsi untuk mengubah list hasil deteksi ketidaksesuaian ke bentuk laporan. Karena laporan yang dihasilkan berupa daftar yang mengelompokkan kalimat alur kejadian kasus penggunaan dan triplet secara terpisah dengan penanda warna untuk membedakan label kesesuaian, list hasil deteksi ketidaksesuaian harus diolah kembali. Pengolahan tersebut dapat dilihat pada Kode Sumber 4.16. Pengolahan dimulai dengan mengambil jenis format berkas laporan (baris ke-2).

Kode Sumber 4.16 Potongan kode mengekspor hasil deteksi ketidaksesuaian ke bentuk laporan 1

2 3

4

public void exportToReport(List ,→ rowDetectionResult, List<String> triplet, String ,→ filePath) { String fileExtension = FileHandler.getFileExtension( ,→ filePath); UseCaseDescriptionDetectionResult ucdResult = ,→ DetectionResultUtil.getUcdDetectionResult( ,→ rowDetectionResult); TripletDetectionResult tripletResult = ,→ DetectionResultUtil.getTripletDetectionResult ,→ (rowDetectionResult, triplet);

5 6

if (fileExtension.equals("doc") fileExtension. ,→ equals("docx")) { WordProcessorFormatWriter wordProcessorFormat = ,→ new WordProcessorFormatWriter(); wordProcessorFormat.writeToDocument(ucdResult, ,→ tripletResult, filePath); } else if (fileExtension.equals("pdf")) { PdfFormatWriter pdfFormatWriter = new ,→ PdfFormatWriter(); pdfFormatWriter.writeToDocument(ucdResult, ,→ tripletResult, filePath); }

7 8 9 10 11 12 13

}

183 Kemudian, mengolah kalimat alur kejadian dasar kasus penggunaan (baris ke-3) dan triplet (baris ke-4) hasil deteksi ketidaksesuaian. Proses tersebut dijelaskan pada bagian berikutnya. Melompat ke baris 6 dan baris 9, baris tersebut adalah proses mengecek format berkas laporan yang akan diekspor. Jika format “.doc” atau “.docx”, hasil deteksi ketidaksesuaian diekspor ke laporan dalam format tersebut oleh kelas WordProcessorFormatWriter. Namun, jika format “.pdf”, hasil deteksi ketidaksesuaian diekspor ke laporan oleh kelas PdfFormatWriter. Pembentukan laporan dalam format “.doc” atau “.docx” dibantu oleh pustaka Apache POI [33], sedangkan format “.pdf” dibantu oleh pustaka iText [34]. Kembali menjelaskan pengolahan kalimat alur kejadian dasar kasus penggunaan pada baris ke-3, pengolahan ini ditunjukkan oleh potongan kode fungsi getUcdDetectionResult pada Kode Sumber 4.17. Pengolahan ini mengambil elemen list hasil deteksi ketidaksesuaian, rowDetectionResult, dan memasukkannya kembali ke dalam list dari kelas model UseCaseDescriptionDetectionResult (baris ke-1 dan ke-2).

Kode Sumber 4.17 Potongan kode mengolah kalimat alur kejadian dasar kasus penggunaan hasil deteksi ketidaksesuaian 1

2 3

4 5 6 7 8

9

public static UseCaseDescriptionDetectionResult ,→ getUcdDetectionResult(List ,→ rowDetectionResult) { UseCaseDescriptionDetectionResult result = new ,→ UseCaseDescriptionDetectionResult(); List ,→ detectedUseCaseDescriptions = new ArrayList ,→ <>(); for (int i = 0; i < rowDetectionResult.size(); i++) ,→ { result.setUseCaseName(rowDetectionResult.get(i). ,→ getUseCaseName()); DetectedUseCaseDescription ,→ detectedUseCaseDescription = new ,→ DetectedUseCaseDescription(); detectedUseCaseDescription.setUseCaseDescription ,→ (rowDetectionResult.get(i). ,→ getUseCaseDescription());

184 10

detectedUseCaseDescription.setLabel( ,→ rowDetectionResult.get(i).getLabel()); detectedUseCaseDescriptions.add( ,→ detectedUseCaseDescription); result.setDetectedUseCaseDescription( ,→ detectedUseCaseDescriptions);

11 12 13 14 15

} return result;

Proses memasukkan dapat dilihat pada baris ke-5 sampai baris ke-13. Kelas UseCaseDescriptionDetectionResult terdiri dari nama kasus penggunaan (baris ke-6) dan list DetectedUseCaseDescription yang terdiri dari kalimat alur kejadian kasus penggunaan (baris ke-9) dan label kesesuaian (baris ke-10). Pengolahan triplet berbeda dengan pengolahan kalimat alur kejadian dasar kasus penggunaan karena list hasil deteksi ketidaksesuaian (rowDetectionResult) hanya menyimpan informasi triplet dengan label “Sesuai”. Untuk mendapatkan triplet dengan label baik “Sesuai” maupun “Tidak sesuai”, proses pada Kode Sumber 4.18 dilakukan. Terdapat kelas model TripletDetectionResult pada baris ke-2.

Kode Sumber 4.18 Potongan kode mengolah triplet hasil deteksi ketidaksesuaian 1

2 3 4 5

6 7 8

public static TripletDetectionResult ,→ getTripletDetectionResult(List rowDetectionResult, List<String> triplet) { TripletDetectionResult result = new ,→ TripletDetectionResult(); List detectedTriplets = new ,→ ArrayList<>(); List<String> consistentTriplets = ,→ getConsistentTriplet(rowDetectionResult); List<String> inconsistentTriplets = ,→ getInconsistentTriplet(rowDetectionResult, ,→ triplet); String useCaseName = rowDetectionResult.get(0). ,→ getUseCaseName(); for (int i = 0; i < triplet.size(); i++) {

185 9 10 11

result.setUseCaseName(useCaseName); for (int j = 0; j < consistentTriplets.size(); j ,→ ++) { if (triplet.get(i).equals(consistentTriplets ,→ .get(j))) { DetectedTriplet detectedTriplet = new ,→ DetectedTriplet();

12 13 14 15

detectedTriplet. ,→ setSequenceDiagramTriplet(triplet ,→ .get(i)); detectedTriplet.setLabel("Sesuai"); detectedTriplets.add(detectedTriplet); break;

16 17 18 19 20 21 22

} } for (int j = 0; j < inconsistentTriplets.size(); ,→ j++) { if (triplet.get(i).equals( ,→ inconsistentTriplets.get(j))) { DetectedTriplet detectedTriplet = new ,→ DetectedTriplet();

23 24 25 26

detectedTriplet. ,→ setSequenceDiagramTriplet(triplet ,→ .get(i)); detectedTriplet.setLabel("Tidak sesuai") ,→ ; detectedTriplets.add(detectedTriplet); ...

27 28 29 30 31 32 33 34 35 36

} } result.setDetectedTriplet(detectedTriplets); } return result;

Kelas TripletDetectionResult berisi nama kasus penggunaan dan

186 list dari triplet yang telah diolah. List dari triplet yang telah diolah ditunjukkan oleh detectedTriplets pada baris ke-3. List tersebut berisi triplet dan label kesesuaian. Selanjutnya, ada list consistentTriplets yang menampung triplet dengan label “Sesuai” (baris ke-4) dan inconsistentTriplets yang menampung triplet dengan label “Tidak sesuai” (baris ke-5) dari hasil deteksi ketidaksesuaian. Triplet dengan label “Sesuai” didapatkan dengan menjalankan fungsi getConsistentTriplet. Fungsi ini langsung memasukkan semua triplet dengan label “Sesuai” dari list hasil deteksi ketidaksesuaian. Sedangkan, triplet dengan label “Tidak sesuai” didapatkan dengan menjalankan fungsi getInconsistentTriplet. Fungsi ini mengambil triplet dengan label “Tidak sesuai” dengan mengurangi elemen keseluruhan triplet pada kasus penggunaan saat ini, triplet, dengan triplet dengan label “Sesuai”. Sehingga, triplet yang dihasilkan adalah triplet dengan label “Tidak sesuai”. Hasil triplet yang telah ditampung tersebut kemudian disimpan ke dalam kelas model TripletDetectionResult melalui proses yang ditunjukkan oleh baris ke-8 sampai dengan baris ke-27.

BAB V PENGUJIAN DAN EVALUASI

Bab ini menjelaskan pengujian dan evaluasi dari kakas bantu yang telah dibuat. Pengujian dibagi menjadi tiga bagian, yaitu pengujian hasil deteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram), pengujian fungsional, dan pengujian non-fungsional kakas bantu. Evaluasi berisi analisis dari hasil masing-masing pengujian.

5.1 Lingkungan Pengujian Lingkungan pengujian kakas bantu dilakukan dengan menggunakan komputer dengan spesifikasi Intel® Core™ i3-2330M CPU @ 2.20 GHz dengan memori sebesar 4 GB. Selain itu, terdapat perangkat lunak yang membantu selama proses pengujian. Perangkat lunak tersebut antara lain: • Sistem operasi Linux Ubuntu 16.04.1 LTS (Xenial Xerus) 64-bit. • Oracle Java Development Kit (JDK) versi 1.8.0_112. • Aplikasi pemodelan StarUML 2 versi 2.8.0 dengan XMI extension versi 0.9.2. • Basis data leksikal bahasa Inggris WordNet 3.1.

5.2 Data Pengujian Data pengujian yang digunakan untuk menguji hasil deteksi ketidaksesuaian diagram urutan dengan diagram kasus penggunaan adalah dokumen rancangan yang berisi diagram kasus penggunaan, deskripsi kasus penggunaan (use case description), dan diagram urutan dari sebuah sistem atau proyek perangkat lunak. Untuk mendapatkan data uji coba tersebut, data yang bersumber dari buku rekayasa perangkat lunak dan internet dipilah. Data yang telah dipilah dimodelkan ulang ke dalam diagram kasus penggunaan beserta deskripsinya dan diagram urutan menggunakan aplikasi StarUML 2. Hasil pemodelan tersebut kemudian diekspor menjadi berkas dokumen rancangan dalam format “.xmi” sesuai penjelasan proses membuat dokumen rancangan pada subbab perancangan sistem. Total pasangan kasus penggunaan dengan diagram urutan yang diambil sejumlah

187

188 12 pasang dari 6 sistem atau proyek perangkat lunak. Dokumen rancangan yang digunakan sebagai data uji coba dilampirkan pada Lampiran B.

5.3

Skenario Pengujian

Skenario pengujian terdiri dari tiga bagian, yaitu skenario pengujian hasil deteksi ketidaksesuaian diagram urutan dengan diagram kasus penggunaan, skenario pengujian fungsional kakas bantu, dan skenario pengujian non-fungsional kakas bantu. Pertama, pengujian hasil deteksi ketidaksesuaian dilakukan dengan menggunakan 12 pasang kasus penggunaan dan diagram urutan yang telah dijelaskan sebelumnya. Ada dua skenario pengujian hasil deteksi ketidaksesuaian. Skenario tersebut, yaitu pengujian hasil deteksi ketidaksesuaian sesuai dengan teori pembuatan diagram urutan dan pengujian hasil deteksi ketidaksesuaian dengan membandingkan hasil dari kakas bantu dan penilaian manual dari ahli rekayasa perangkat lunak. Hasil deteksi ketidaksesuaian sesuai teori pembuatan diagram urutan berfungsi untuk mengetahui apakah kakas bantu yang dibuat sudah sesuai dengan teori tersebut. Untuk hasil deteksi ketidaksesuaian yang melibatkan ahli, hasil deteksi oleh kakas bantu dan ahli dibandingkan dengan menghitung nilai kappa statistic. Nilai kappa statistic digunakan untuk mengukur kesepakatan antara dua pengamat. Kedua, pengujian fungsional kakas bantu. Pengujian fungsional kakas bantu menggunakan pengujian black-box. Pengujian black-box adalah pengujian yang menguji fungsionalitas perangkat lunak apakah sudah sesuai dengan hasil yang diharapkan. Pengujian ini dilakukan dengan menyiapkan sebuah skenario yang merujuk kepada kasus penggunaan (use case). Kemudian, partisipan diberikan tugas untuk menjalankan skenario tersebut. Skenario pengujian ini terdiri dari dua pengujian fitur utama kakas bantu, yaitu pengujian fitur memeriksa ketidaksesuaian dokumen rancangan dan mengekspor laporan hasil pemeriksaan ketidaksesuaian. Hasil pengujian fungsional dari setiap skenario ditentukan dengan membandingkan hasil yang didapatkan dengan hasil yang diharapkan. Ketiga, pengujian non-fungsional kakas bantu. Pengujian non-fungsional dilakukan untuk aspek usability sesuai penjelasan subbab kebutuhan non-fungsional. Partisipan diberikan tugas untuk menjalankan dua fitur utama kakas bantu seperti yang telah dijelaskan sebelumnya. Di awal, partisipan telah diberikan penjelasan mengenai kakas bantu. Setelah parti-

189 sipan selesai menjalankan tugas, partisipan diminta untuk mengisi sebuah kuesioner. Kuesoner diberikan untuk mengetahui seberapa besar tingkat kemudahan penggunaan kakas bantu. Kuesioner terdiri dari dua bagian, yaitu bagian yang berisi pernyataan dan bagian yang berisi pertanyaan. Pernyataan dan pertanyaan berhubungan dengan aspek usability.

5.3.1 Pengujian Hasil Deteksi Ketidaksesuaian Berdasarkan pengujian data pelatihan, nilai ambang batas (threshold) terbaik untuk kemiripan kalimat alur kejadian dasar pada deskripsi kasus penggunaan dengan triplet adalah 0,47. Nilai tersebut terjadi saat memberikan bobot kemiripan kata benda 0,65 dan kata kerja 0,35. Data pelatihan berupa dokumen rancangan yang berisi 8 pasang kasus penggunaan dan diagram urutan dari 7 sistem yang berbeda dengan data pengujian. Nilai ambang batas ini digunakan untuk skenario pengujian hasil deteksi ketidaksesuaian. Untuk skenario pengujian hasil deteksi ketidaksesuaian yang membandingkan hasil deteksi ketidaksesuaian antara kakas bantu dan ahli rekayasa perangkat lunak, hasil pengujian dinilai dari kesepakatan antara kakas bantu dan ahli rekayasa perangkat lunak melalui perhitungan kappa statistic. Perhitungan kappa statistic menggunakan konsep yang diajukan oleh Gwet [35]. Perhitungan tersebut diilustrasikan melalui contoh kasus berikut. Terdapat sebuah percobaan di mana pengamat A dan B mengelompokkan 100 data ke dalam dua kategori yang diberikan label “1” dan “2”. Hasil percobaan ini ditunjukkan oleh Tabel 5.1.

Tabel 5.1 Hasil sebuah percobaan Pengamat A “1” “2” Jumlah

Pengamat B “1”

“2”

Jumlah

40 6 46

9 45 54

49 51 100

Perhitungan kappa statistic dimulai dengan menghitung nilai e(γ). e(γ) adalah probabilitas chance-agreement yang dihitung melalui Persa-

190 maan 5.1: e(γ) = 2 × P1 (1 − P1 )

(5.1)

di mana P1 merepresentasikan perkiraan kemungkinan seorang pengamat (A atau B) mengelompokkan data ke dalam kategori “1”. Nilai P1 dihitung dengan persamaan: (A1 + B1) (5.2) P1 = 2×N A1 dan B1 masing-masing adalah jumlah pengamat A atau B mengelompokkan data ke dalam kategori “1”, sedangkan N adalah jumlah data. Sehingga, nilai e(γ) dari hasil percobaan pada Tabel 5.1 adalah: ( )( ) 46 + 49 46 + 49 e(γ) = 2 1− = 0,49875 (5.3) 2 × 100 2 × 100 Nilai kappa statistic dapat dihitung setelah mendapatkan nilai e(γ). Nilai kappa statistic yang dinotasikan dengan AC1 dihitung menggunakan Persamaan 5.4. p − e(γ) AC1 = (5.4) 1 − e(γ) di mana p adalah proporsi kesepakatan keseluruhan yang dihitung melalui persamaan: (A + D) p= (5.5) N A adalah banyaknya data yang dikelompokkan ke dalam kategori “1” oleh kedua pengamat. D adalah banyaknya data yang dikelompokkan ke dalam kategori “2” oleh kedua pengamat. Sehingga, hasil percobaan pada Tabel 5.1 memiliki nilai kappa statistic: AC1 =

(0,85 − 0,49875) = 0,70074 (1 − 0,49875)

(5.6)

dengan nilai p, (40 + 45) = 0,85 (5.7) 100 Nilai kappa statistic sejumlah 0,70074 termasuk ke dalam kategori substansial menurut Landis dan Koch [36]. Untuk skenario pengujian ini, hasil pengujian dikelompokkan ke dap=

191 lam dua kategori dengan label “Sesuai” dan “Tidak sesuai”. Adapun ahli yang terlibat dalam pengujian ini. Pengujian melibatkan dua ahli rekayasa perangkat lunak. Dua ahli tersebut memiliki kemampuan dan pengalaman di bidang analisis dan perancangan sistem (sistems analysis & design) dan rekayasa kebutuhan (software requirements) khususnya pemodelan diagram kasus penggunaan dan diagram urutan. Dari hasil pengujian ini, nilai kappa statistic antara kakas bantu dengan ahli pertama dan kakas bantu dengan ahli kedua dihitung. Skenario dan hasil pengujian dari pengujian hasil deteksi ketidaksesuaian selanjutnya dijelaskan melalui subbab berikut ini.

5.3.1.1 Pengujian Hasil Deteksi Ketidaksesuaian Kakas Bantu Sesuai Teori Pembuatan Sequence Diagram Sebuah diagram urutan dibuat berdasarkan alur kejadian yang ada pada kasus penggunaan. Proses tersebut dilakukan setelah analisis kelas (class analysis) selesai dilakukan. Analisis kelas merupakan proses menentukan kelas-kelas yang terlibat dalam sebuah sistem. Tahapan analisis kelas, yaitu melengkapi penjelasan alur kejadian kasus penggunaan, menentukan kandidat kelas, menjabarkan tanggung jawab kelas, dan mendeskripsikan atribut dan hubungan kelas. Kandidat kelas diidentifikasi melalui kata benda yang ada pada alur kejadian suatu kasus penggunaan, sedangkan tanggung jawab kelas diidentifikasi melalui kata kerja. Sesuai teori di atas, skenario pengujian ini dilakukan untuk mengetahui apakah kakas bantu yang dibuat sudah memenuhi teori tersebut. Pengujian menggunakan sebuah dokumen rancangan yang telah dibuat. Dokumen rancangan adalah sebuah sistem dengan nama “Student Activity Unit”. Di dalamnya, terdapat sebuah kasus penggunaan “Upload Event Proposal” dengan aktor “SAU Manager”. Deskripsi dari kasus penggunaan ini dijabarkan sebagai berikut: 1. The SAU manager selects the option to upload event proposal. 2. The system displays a form. 3. The SAU manager fills out the form. 4. The SAU manager clicks the ”Upload” button. 5. The system displays success message. Setalah melewati tahapan yang ada pada analisis kelas, diagram urutan dari kasus penggunaan “Upload Event Proposal” ditunjukkan oleh Gambar 5.1.

192

Gambar 5.1 Diagram urutan (sequence diagram) “Upload Event Proposal”

Gambar 5.2 Hasil deteksi ketidaksesuaian kasus penggunaan “Upload Event Proposal” Apabila dengan dokumen rancangan tersebut dideteksi ketidakse-

193 suaiannya dengan kakas bantu yang dibuat, hasil deteksi ketidaksesuaian ditunjukkan oleh Gambar 5.2. Gambar menunjukkan tidak ditemukan ketidaksesuaian antara diagram urutan dengan deskripsi kasus penggunaannya. Selanjutnya, mencoba deteksi ketidaksesuaian apabila salah satu alur dari deskripsi kasus penggunaan dibalik. Alur nomor 3 dan nomor 4 dari deskripsi kasus penggunaan “Upload Event Proposal” ditukar posisinya.

Gambar 5.3 Hasil deteksi ketidaksesuaian kasus penggunaan “Upload Event Proposal” (alur deskripsi terbalik) Hasil deteksi ketidaksesuaian untuk kasus tersebut ditunjukkan oleh Gambar 5.3. Sesuai dengan gambar, ketidaksesuaian antara diagram urutan dengan deskripsi kasus penggunaannya ditemukan. Alur deskripsi kasus penggunaan nomor 4 dan triplet diagram urutan nomor 3 tidak sesuai. Hal ini terjadi karena alur “The SAU Manager fills out the form” yang seharusnya berada pada nomor 3, namun urutan triplet-nya pada diagram urutan berada nomor 4. Terakhir, mencoba deteksi ketidaksesuaian dengan menghapus salah satu alur dari deskripsi kasus penggunaan. Misal, alur deskripsi kasus penggunaan nomor 5 dihapus. Hasil deteksi ketidaksesuaian untuk kasus ini ditunjukkan oleh Gambar 5.4. Gambar menjelaskan bahwa ketidaksesuaian antara diagram urutan dan deskripsinya ditemukan. Ketidaksesu-

194 aian disebabkan oleh triplet “{FormController, displayMessage(), EventProposalForm}. Triplet tersebut tidak sesuai karena alur yang direalisasikan oleh triplet ini tidak ada.

Gambar 5.4 Hasil deteksi ketidaksesuaian kasus penggunaan “Upload Event Proposal” (salah satu alur deskripsi hilang)

5.3.1.2

Pengujian Hasil Deteksi Ketidaksesuaian antara Kakas Bantu dan Ahli

Sesuai penjelasan sebelumnya, terdapat pengujian hasil deteksi ketidaksesuaian antara kakas bantu dan ahli rekayasa perangkat lunak. Pengujian ini melibatkan dua ahli rekayasa perangkat lunak. Pengujian menggunakan data dokumen rancangan sesuai penjelasan yang telah dideskripsikan pada subbab data pengujian. Pengujian tersebut dijabarkan ke dalam 6 kasus sesuai dengan jumlah sistem yang ada pada dokumen rancangan. Hasil percobaan dari masing-masing sistem dijabarkan sebagai berikut: 1. ARENA Dari 48 pasang kalimat alur kejadian dasar pada deskripsi kasus penggunaan dan triplet pada sistem ARENA, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 8 pasang, 1 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama,

195 1 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 38 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil tersebut ditampilkan oleh Tabel 5.2.

Tabel 5.2 Hasil deteksi ketidaksesuaian sistem “ARENA” antara kakas bantu dengan ahli pertama Ahli Pertama Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

8 1 9

1 38 39

9 39 48

Dengan perhitungan kappa statistic, hasil percobaan di atas menghasilkan nilai kesepakatan 0,94. Selanjutnya percobaan dengan ahli kedua, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 8 pasang, 1 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama, 0 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 39 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil tersebut ditampilkan oleh Tabel 5.3.

Tabel 5.3 Hasil deteksi ketidaksesuaian sistem “ARENA” antara kakas bantu dengan ahli kedua Ahli Kedua Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

8 0 8

1 39 40

9 39 48

Sesuai tabel tersebut, hasil percobaan menghasilkan nilai kesepakatan 0,97 melalui perhitungan kappa statistic.

196 2. ATM Terdapat 7 pasang kalimat alur kejadian dasar pada deskripsi kasus penggunaan dan triplet pada sistem ATM. Untuk percobaan dengan ahli pertama, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 2 pasang, 1 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama, 0 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 4 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil percobaan ini ditampilkan oleh Tabel 5.4.

Tabel 5.4 Hasil deteksi ketidaksesuaian sistem “ATM” antara kakas bantu dengan ahli pertama Ahli Pertama Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

2 0 2

1 4 5

3 4 7

Dengan perhitungan kappa statistic, hasil percobaan di atas menghasilkan nilai kesepakatan 0,735. Percobaan dengan ahli kedua menghasilkan hasil yang sama dengan percobaan pertama. Sehingga, hasil percobaan kedua menghasilkan nilai kesepakatan yang sama dengan percobaan pertama sejumlah 0,735. 3. Simple Address Book Sistem Simple Address Book memiliki 24 pasang kalimat alur kejadian dasar pada deskripsi kasus penggunaan dan triplet. Melalui percobaan dengan ahli pertama, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 0 pasang, 4 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama, 1 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 19 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil percobaan ini ditampilkan oleh Tabel 5.5. Dengan perhitungan kappa statistic, hasil percobaan pada tabel tersebut menghasilkan nilai kesepakatan 0,743. Untuk percobaan dengan ahli kedua, kakas bantu dan ahli kedua memberikan label “Sesuai” sebanyak 0 pasang, 0 pa-

197 sang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama, 0 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 0 pasang diberikan label “Tidak sesuai” oleh keduanya.

Tabel 5.5 Hasil deteksi ketidaksesuaian sistem “Simple Address Book” antara kakas bantu dengan ahli pertama Ahli Pertama Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

0 1 1

4 19 23

4 20 24

Hasil percobaan ini ditampilkan oleh Tabel 5.6. Dari tabel tersebut, hasil percobaan kedua memiliki nilai kesepakatan 0,68.

Tabel 5.6 Hasil deteksi ketidaksesuaian sistem “Simple Address Book” antara kakas bantu dengan ahli kedua Ahli Kedua Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

0 1 1

5 18 23

5 19 24

4. Online Shopping System Sistem Online Shopping System memiliki 4 pasang kalimat alur kejadian dasar pada deskripsi kasus penggunaan dan triplet. Melalui percobaan dengan ahli pertama, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 1 pasang, 1 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama, 0 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh

198 ahli pertama, dan 2 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil percobaan ini ditampilkan oleh Tabel 5.7.

Tabel 5.7 Hasil deteksi ketidaksesuaian sistem “Online Shopping System” antara kakas bantu dengan ahli pertama Ahli Pertama Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

1 0 1

1 2 3

2 2 4

Dengan perhitungan kappa statistic, hasil percobaan di atas menghasilkan nilai kesepakatan 0,53. Percobaan dengan ahli kedua menghasilkan penilaian yang sama dengan percobaan pertama. Sehingga, hasil percobaan kedua menghasilkan nilai kesepakatan yang sama dengan percobaan pertama sejumlah 0,53. 5. Emergency Monitoring System Ada 4 pasang kalimat alur kejadian dasar pada deskripsi kasus penggunaan dan triplet pada sistem Emergency Monitoring System.

Tabel 5.8 Hasil deteksi ketidaksesuaian sistem “Emergency Monitoring System” antara kakas bantu dengan ahli pertama Ahli Pertama Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

1 0 1

1 2 3

2 2 4

Melalui percobaan dengan ahli pertama, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 1 pasang, 1 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli

199 pertama, 0 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 2 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil percobaan ini ditampilkan oleh Tabel 5.8. Dengan perhitungan kappa statistic, hasil percobaan pada tabel tersebut menghasilkan nilai kesepakatan 0,53. Percobaan dengan ahli kedua menghasilkan penilaian yang sama dengan percobaan pertama. Sehingga, hasil percobaan kedua menghasilkan nilai kesepakatan yang sama dengan percobaan pertama sejumlah 0,53. 6. Community Peace Program Ada 10 pasang kalimat alur kejadian dasar pada deskripsi kasus penggunaan dan triplet pada sistem Community Peace Program. Melalui percobaan dengan ahli pertama, kakas bantu dan ahli pertama memberikan label “Sesuai” sebanyak 2 pasang, 0 pasang diberikan label “Tidak sesuai” oleh kakas bantu, namun “Sesuai” oleh ahli pertama, 0 pasang diberikan label “Sesuai” oleh kakas bantu, namun “Tidak sesuai” oleh ahli pertama, dan 8 pasang diberikan label “Tidak sesuai” oleh keduanya. Hasil percobaan ini ditampilkan oleh Tabel 5.9.

Tabel 5.9 Hasil deteksi ketidaksesuaian sistem “Community Peace Program” antara kakas bantu dengan ahli pertama Ahli Pertama Sesuai Tidak sesuai Jumlah

Kakas Bantu Sesuai

Tidak sesuai

Jumlah

2 0 2

0 8 8

2 8 10

Dengan perhitungan kappa statistic, hasil percobaan di atas menghasilkan nilai kesepakatan 1,0. Percobaan dengan ahli kedua menghasilkan penilaian yang sama dengan percobaan pertama. Sehingga, hasil percobaan kedua menghasilkan nilai kesepakatan yang sama dengan percobaan pertama sejumlah 1,0. Dari percobaan hasil deteksi ketidaksesuaian yang telah dilakukan, nilai kappa statistic untuk setiap kasus antara kakas bantu dengan ahli dijabarkan. Penjabaran tersebut dijabarkan oleh Tabel 5.10. Kedua ahli memiliki nilai kesepakatan yang sama dengan kakas bantu untuk kasus ATM,

200 Tabel 5.10 Nilai kappa statistic setiap kasus uji Pengamat

Nama Kasus ARENA

ATM

SAB* OSS† EMS‡ CPP§

Kakas bantuAhli pertama

0,94

0,74

0,74

0,53

0,53

1,00

Kakas bantuAhli kedua

0,97

0,74

0,68

0,53

0,53

1,00

* † ‡ §

Simple Address Book. Online Shopping System. Emergency Monitoring System. Community Peace Program.

Online Shopping System, Emergency Monitoring System, dan Community Peace Program sesuai tabel tersebut. Ada perbedaan nilai kesepakatan antar kedua ahli untuk kasus ARENA dan Simple Address Book. Kasus ARENA memiliki selisih nilai kesepakatan sejumlah 0,03, sedangkan Simple Address Book sejumlah 0,06. Perbedaan nilai tersebut tidak terlalu signifikan. Nilai kesepakatan tertinggi dari kedua ahli terjadi pada kasus Community Peace Program dengan nilai 1,00. Kemudian, nilai kesepakatan turun ke 0,74 oleh kasus ATM dan Simple Address Book. Nilai kesepakatan terendah terjadi pada kasus Online Shopping System dan Emergency Monitoring System. Apabila total dari 6 kasus tersebut dihitung secara keseluruhan, nilai kesepakatan kakas bantu dengan ahli pertama didapatkan sejumlah 0,85 dan kakas bantu dengan ahli kedua sejumlah 0,82. Nilai kesepakatan tersebut berbeda 0,03.

5.3.2

Pengujian Fungsional

Sesuai penjelasan sebelumnya, pengujian fungsional kakas bantu melalui black-box testing dengan menyiapkan skenario sebagai tolak ukur keberhasilan. Adapun partisipan yang terlibat dalam pengujian ini. Partisipan tersebut adalah mahasiswa Teknik Informatika ITS dengan kua-

201 lifikasi telah lulus mata kuliah Analisis Perancangan Sistem Informasi. Jumlah mahasiswa yang terlibat adalah 10 orang. Selanjutnya, pengujian ini dijabarkan sebagai berikut.

5.3.2.1 Pengujian Fitur Memeriksa Ketidaksesuaian Dokumen Rancangan Pengujian ini digunakan untuk menguji fitur memeriksa ketidaksesuaian dokumen rancangan apakah sudah sesuai dengan hasil yang diharapkan. Pengujian fitur ini terdiri dari dua skenario. Skenario pertama dijabarkan oleh Tabel 5.11.

Tabel 5.11 Skenario pertama pengujian fitur memeriksa ketidaksesuaian dokumen rancangan Nama pengujian Tujuan pengujian Referensi kasus penggunaan Skenario

Kondisi awal

Pengujian fitur memeriksa ketidaksesuaian dokumen rancangan Menguji fitur untuk memeriksa ketidaksesuaian dokumen rancangan. Memeriksa Ketidaksesuaian Dokumen Rancangan Partisipan memeriksa dokumen rancangan dengan memasukkan berkas dokumen rancangan dengan format yang benar, yaitu “.xmi”. Dokumen rancangan belum diperiksa ketidaksesuaiannya.

202 Tabel 5.11 Skenario pertama pengujian fitur memeriksa ketidaksesuaian dokumen rancangan (lanjutan) Langkah pengujian

Hasil yang diharapkan

Hasil yang didapatkan

Kondisi akhir Hasil pengujian

1. Menekan tombol “Masukan berkas...” pada layar utama kakas utama. 2. Memilih dokumen rancangan pada lokasi di mana dokumen rancangan disimpan. 3. Menekan tombol “Open” pada jendela “Masukan berkas dokumen rancangan”. 4. Menekan tombol “Lakukan deteksi” pada layar utama kakas bantu. Kakas bantu menampilkan hasil deteksi ketidaksesuaian pada layar utama kakas bantu. Kakas bantu menampilkan hasil deteksi ketidaksesuaian pada layar utama kakas bantu. Ketidaksesuaian pada dokumen rancangan ditemukan atau tidak ditemukan. Berhasil

Gambar 5.5 Hasil deteksi ketidaksesuaian pada antarmuka utama kakas bantu

203 Hasil yang didapatkan pada skenario pertama, yaitu berupa daftar yang berisi hasil deteksi ketidaksesuaian dokumen rancangan. Daftar tersebut dapat dilihat pada Gambar 5.5. Selanjutnya, skenario kedua dari fitur memeriksa ketidaksesuaian dokumen rancangan dijabarkan oleh Tabel 5.12.

Tabel 5.12 Skenario kedua pengujian fitur memeriksa ketidaksesuaian dokumen rancangan Nama pengujian Tujuan pengujian Referensi kasus penggunaan Skenario

Kondisi awal Langkah pengujian


Hasil yang didapatkan

Kondisi akhir

Pengujian fitur memeriksa ketidaksesuaian dokumen rancangan Menguji fitur untuk memeriksa ketidaksesuaian dokumen rancangan. Memeriksa Ketidaksesuaian Dokumen Rancangan Partisipan memeriksa dokumen rancangan dengan memasukkan berkas dokumen rancangan dengan format yang salah. Dokumen rancangan belum diperiksa ketidaksesuaiannya. 1. Menekan tombol “Masukan berkas...” pada layar utama kakas utama. 2. Memilih dokumen rancangan pada lokasi di mana dokumen rancangan disimpan. 3. Menekan tombol “Open” pada jendela “Masukan berkas dokumen rancangan”. Kakas bantu menampilkan pesan bahwa format berkas dokumen rancangan yang dimasukkan tidak sesuai. Kakas bantu menampilkan pesan bahwa format berkas dokumen rancangan yang dimasukkan tidak sesuai. Dokumen rancangan tidak berhasil diperiksa ketidaksesuaiannya.

204 Tabel 5.12 Skenario kedua pengujian fitur memeriksa ketidaksesuaian dokumen rancangan (lanjutan) Hasil pengujian

Berhasil

Hasil yang didapatkan pada skenario kedua, yaitu pesan peringatan jika format berkas dokumen rancangan tidak sesuai. Format yang sesuai adalah “.xmi”. Pesan tersebut ditunjukkan oleh Gambar 5.6.

Gambar 5.6 Pesan kesalahan format berkas dokumen rancangan

5.3.2.2

Pengujian Fitur Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian

Pengujian ini digunakan untuk menguji fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian apakah sudah sesuai dengan hasil yang diharapkan. Pengujian fitur ini juga terdiri dari dua skenario. Skenario pertama dijabarkan oleh Tabel 5.13.

Tabel 5.13 Skenario pertama pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian Nama pengujian Tujuan pengujian

Referensi kasus penggunaan

Pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian Menguji fitur untuk mengekspor hasil pemeriksaan ketidaksesuaian ke dalam bentuk laporan. Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian

205 Tabel 5.13 Skenario pertama pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian (lanjutan) Skenario

Kondisi awal

Langkah pengujian

Hasil yang diharapkan Hasil yang didapatkan Kondisi akhir

Hasil pengujian

Partisipan menyimpan lokasi dan nama berkas laporan hasil deteksi ketidaksesuaian dengan format yang benar, yaitu “.doc”, “.docx”, atau “.pdf”. Lokasi tempat berkas laporan disimpan belum ditampilkan pada layar utama kakas bantu. 1. Mencentang opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” pada layar utama kakas bantu. 2. Menekan tombol “Simpan hasil...”. 3. Memilih lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian. 4. Memilih jenis format laporan hasil pemeriksaan ketidaksesuaian. 5. Memasukkan nama berkas laporan hasil pemeriksaan ketidaksesuaian. 6. Menekan tombol “Save”. Kakas bantu menampilkan lokasi tempat berkas laporan disimpan. Kakas bantu menampilkan lokasi tempat berkas laporan disimpan. Lokasi tempat berkas laporan disimpan ditampilkan pada layar utama kakas bantu. Berhasil

Hasil yang didapatkan pada skenario pertama, yaitu lokasi di mana laporan hasil deteksi ketidaksesuaian ditampilkan pada layar utama kakas bantu. Lokasi tersebut dapat dilihat pada Gambar 5.7. Selanjutnya, skenario kedua dari fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian dijabarkan oleh Tabel 5.14

206

Gambar 5.7 Pesan kesalahan format berkas dokumen rancangan Tabel 5.14 Skenario kedua pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian Nama pengujian Tujuan pengujian

Referensi kasus penggunaan Skenario

Kondisi awal

Langkah pengujian


Pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian Menguji fitur untuk mengekspor hasil pemeriksaan ketidaksesuaian ke dalam bentuk laporan. Mengekspor Laporan Hasil Pemeriksaan Ketidaksesuaian Partisipan menyimpan lokasi dan nama berkas laporan hasil deteksi ketidaksesuaian dengan format yang salah. Lokasi tempat berkas laporan disimpan belum ditampilkan pada layar utama kakas bantu. 1. Mencentang opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” pada layar utama kakas bantu. 2. Menekan tombol “Simpan hasil...”. 3. Memilih lokasi penyimpanan laporan hasil pemeriksaan ketidaksesuaian. 4. Memilih jenis format laporan hasil pemeriksaan ketidaksesuaian. 5. Memasukkan nama berkas laporan hasil pemeriksaan ketidaksesuaian. 6. Menekan tombol “Save”. Kakas bantu menampilkan pesan bahwa format berkas laporan tidak sesuai.

207 Tabel 5.14 Skenario kedua pengujian fitur mengekspor laporan hasil pemeriksaan ketidaksesuaian (lanjutan) Hasil yang didapatkan Kondisi akhir

Hasil pengujian

Kakas bantu menampilkan pesan bahwa format berkas laporan tidak sesuai. Lokasi tempat berkas laporan disimpan tidak ditampilkan pada layar utama kakas bantu. Berhasil

Hasil yang didapatkan pada skenario kedua, yaitu pesan peringatan jika format berkas laporan tidak sesuai. Format yang sesuai adalah “.doc”, “.docx”, atau “.pdf”. Pesan tersebut dapat ditunjukkan oleh Gambar 5.8.

Gambar 5.8 Pesan kesalahan format berkas laporan hasil deteksi ketidaksesuaian

5.3.3 Pengujian Non-fungsional Pengujian non-fungsional kakas bantu dilakukan untuk aspek usability sesuai penjelasan sebelumnya. Untuk menguji aspek tersebut, partisipan harus dilibatkan. Partisipan yang terlibat sama dengan partisipan yang terlibat pada pengujian fungsional kakas bantu. Skenario pengujian ini dilakukan melalui langkah berikut ini: 1. Partisipan diberikan penjelasan mengenai apa dan mengapa kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). 2. Partisipan diminta menjalankan tugas-tugas tertentu. Tugas tersebut merupakan bagian dari fitur yang ada di dalam kakas bantu.

208 3. Partisipan diminta mengisi kuesioner setelah menjalankan tugas-tugas yang diberikan. Selama partisipan menjalankan sebuah tugas, partisipan diperbolehkan untuk mengeksplorasi dan memahami kinerja dari kakas bantu. Kuesioner yang diisi oleh partisipan terdiri dari dua bagian, yaitu bagian yang berisi daftar pernyataan dan bagian yang berisi daftar pertanyaan. Bagian yang berisi daftar pernyataan terdiri dari 8 pernyataan, yaitu: 1. Kakas bantu mudah digunakan. 2. Kakas bantu dapat digunakan tanpa bantuan orang atau instruksi tertulis. 3. Kakas bantu dapat dipelajari dalam waktu kurang dari 5 menit. 4. Tampilan kakas bantu jelas. 5. Informasi atau nama perintah pada kakas bantu mudah dipahami. 6. Kakas bantu menyediakan respon atau pesan kesalahan yang jelas. 7. Kakas bantu menampilkan hasil deteksi ketidaksesuaian yang mudah dipahami. 8. Kakas bantu sangat membantu apabila digunakan untuk mendeteksi ketidaksesuaian antara sequence diagram dengan use case diagram. 9. Kakas bantu direkomendasikan apabila digunakan untuk mendeteksi ketidaksesuaian antara sequence diagram dengan use case diagram. Daftar pernyataan diisi dengan memberikan nilai dari sangat tidak setuju, tidak setuju, netral, setuju, hingga sangat setuju. Masing-masing nilai tersebut diberikan bobot yang berbeda yang nantinya digunakan untuk menghitung persentase setiap pernyataan. Bobot 1 untuk sangat tidak setuju, 2 untuk tidak setuju, 3 untuk netral, 4 untuk setuju, dan 5 untuk sangat setuju. Nilai tersebut kemudian dijumlahkan dan dibagi dengan nilai tertinggi penilaian, yaitu 50 (bobot untuk sangat setuju dikali dengan jumlah partisipan). Hasil perhitungan untuk kuesioner ini ditunjukkan oleh Tabel 5.15.

Tabel 5.15 Hasil perhitungan kuesioner dalam bentuk pernyataan Pernyataan Kakas bantu mudah digunakan. Kakas bantu dapat digunakan tanpa bantuan orang atau instruksi tertulis.

Persentase 78% 66%

209 Tabel 5.15 Hasil perhitungan kuesioner dalam bentuk pernyataan (lanjutan) Pernyataan Kakas bantu dapat dipelajari dalam waktu kurang dari 5 menit. Tampilan kakas bantu jelas. Informasi atau nama perintah pada kakas bantu mudah dipahami. Kakas bantu menyediakan respon atau pesan kesalahan yang jelas. Kakas bantu menampilkan hasil deteksi ketidaksesuaian yang mudah dipahami. Kakas bantu sangat membantu apabila digunakan untuk mendeteksi ketidaksesuaian antara sequence diagram dengan use case diagram. Kakas bantu direkomendasikan apabila digunakan untuk mendeteksi ketidaksesuaian antara sequence diagram dengan use case diagram.

Persentase 80% 66% 70% 50% 70% 82%

80%

Sedangkan, bagian yang berisi daftar pertanyaan terdiri dari 5 pertanyaan. Pertanyaan tersebut antara lain: 1. Apa saja kesulitan yang Anda hadapi selama menggunakan kakas bantu? 2. Bagaimana pendapat Anda dengan tampilan kakas bantu? 3. Bagaimana pendapat Anda dengan hasil deteksi ketidaksesuaian yang dihasilkan oleh kakas bantu? 4. Apakah Anda puas dengan hasil deteksi ketidaksesuaian yang dihasilkan oleh kakas bantu? 5. Kritik dan saran Anda untuk perbaikan kakas bantu ke depannya? Untuk daftar pertanyaan, partisipan mengisi setiap pertanyaan dengan pendapat. Pendapat tersebut digunakan sebagai saran yang akan dipertimbangkan untuk meningkatkan dan memperbaiki kakas bantu ke depannya. Hasil pengisian kuesioner untuk untuk pertanyaan pertama ditunjukkan oleh Tabel 5.16.

210 Tabel 5.16 Hasil pengisian kuesioner untuk pertanyaan pertama No

Nama Partisipan

Hasil Isian

1

Reyhan Arief

2 3

Dwika Setiawan Ahmad Ridwan Fauzi

4

Adhi Nurilham

5

I Putu Pradnyana

6

Daniel Henry

Tombol “Simpan Hasil...” tidak langsung menyimpan berkas, tetapi harus menekan tombol ”Lakukan Deteksi” terlebih dahulu. Belum menemukan kesulitan yang berarti. Ketika aplikasi terbuka, dalam memasukkan data dari use case ke aplikasi, file yang diperlukan untuk dimasukkan harus dalam bentuk XMI; Tidak ada pemberitahuan bahwa file XMI yang harus dimasukkan dalam dokumen rancangan; Tidak ada progress bar. Tidak ada, tampilan sederhana dan mudah dipahami. Waktu yang diperlukan untuk menganalisa sebuah dokumen cukup lama. Ada istilah yang susah dipahami orang awam (seperti saya), seperti kata triplet; Tidak ada log yang ditampilkan ketika proses pendeteksian sedang berlangsung; Tidak ada tanda yang menunjukkan bahwa proses pendeteksian sedang berjalan; Hasil deteksi yang dihasilkan membingungkan karena ada tulisan warna merah dan hijau tanda adanya keterangan makna dari tulisan warna merah dan warna hijau; Hasil deteksi membingungkan karena tidak dipasang-pasangkan antara kalimat use case description dengan triplet sequence diagram yang sesuai.

211 Tabel 5.16 Hasil pengisian kuesioner untuk pertanyaan pertama (lanjutan) No

Nama Partisipan

Hasil Isian

7

M. Ardhinata Juari

8 9

Arif Fathur M. Bekti Galan P.

10

M. Husain Fuad D.

Tampilan visual minim teks pembantu; Saat melakukan proses tidak ada indikator kalau proses sedang berlangsung atau tidak. Tidak ada menu help. Performa cukup lama; Tidak tersedianya menu help, jadi instruksi manual dari developer. Namun, tampilan program yang sederhana dapat dengan mudah dipahami. Kurang adanya umpan balik pada pengguna informasi pemuatan proses sehingga pengguna menganggap aplikasi tidak berjalan.

Hasil isian untuk pertanyaan kedua, bagaimana pendapat Anda dengan tampilan kakas bantu?, ditunjukkan oleh Tabel 5.17.

Tabel 5.17 Hasil pengisian kuesioner untuk pertanyaan kedua No

Nama Partisipan

Hasil Isian

1

Reyhan Arief

2

Dwika Setiawan

3

Ahmad Ridwan Fauzi

4

Adhi Nurilham

Saya tidak tahu apakah program sedang memproses input atau mengalami error. Terlalu sederhana; Belum ada tampilan yang menunjukkan progres pendeteksian. Simpel; Kurang informatif sehingga ada kemungkinan pengguna tidak mengetahui apa yang harus dilakukan tanpa melihat manual. Tampilan sangat sederhana dan mudah dipahami.

212 Tabel 5.17 Hasil pengisian kuesioner untuk pertanyaan kedua (lanjutan) No

Nama Partisipan

Hasil Isian

5

I Putu Pradnyana

6

Daniel Henry

7

M. Ardhinata Juari

8 9 10

Arif Fathur M. Bekti Galan P. M. Husain Fuad D.

Tampilan masih kurang responsif terutama karena kurangnya feedback dari program selama melakukan pemeriksaan terhadap dokumen. Selain itu, tampilan program juga tidak mengikuti tema native dari desktop environment yang digunakan. Tampilan kurang ramah terhadap orang awam (alasannya sudah tertera pada jawaban pertanyaan pertama). Normal, tetapi peletakan field, button, dan label terasa kurang pas. Kurang terbiasa dengan bahasa tampilan. Simple, useful. Tampilan aplikasi sederhana dan mudah untuk digunakan.

Hasil isian untuk pertanyaan kedua, bagaimana pendapat Anda dengan hasil deteksi ketidaksesuaian yang dihasilkan oleh kakas bantu?, ditunjukkan oleh Tabel 5.18.

Tabel 5.18 Hasil pengisian kuesioner untuk pertanyaan ketiga No 1 2 3

Nama Partisipan

Hasil Isian

Reyhan Arief Dwika Setiawan Ahmad Ridwan Fauzi

Hasilnya sesuai dengan yang diharapkan. Cukup akurat. Tidak masalah, namun keterangan warna tulisan lebih baik ditempatkan di atas agar pengguna mengetahui terlebih dahulu maksud dari masing-masing warna tulisan.

213 Tabel 5.18 Hasil pengisian kuesioner untuk pertanyaan ketiga (lanjutan) No

Nama Partisipan

Hasil Isian

4

Adhi Nurilham

5

I Putu Pradnyana

6

Daniel Henry

7

M. Ardhinata Juari

8

Arif Fathur M.

9

Bekti Galan P.

10

M. Husain Fuad D.

Hasil deteksi ketidaksesuaian yang dihasilkan dapat dipahami, namun akan lebih baik jika diberikan informasi tambahan tentang kode warna (karena ketidaksesuaian ditandai dengan warna). Laporan yang diberikan sudah cukup baik. Tetapi, untuk memenuhi aturan yang diberikan oleh kakas bantu, kita harus menggunakan pola penamaan yang tidak dapat diketahui tanpa menanyakan kepada penulis secara langsung. Ada hasil deteksi yang sesuai menurut ukuran manusia, namun kakas bantu menganggapnya tidak sesuai. Cara merepresentasikan ketidaksesuaian use case diagram dengan sequence diagram kurang jelas. Pemilihan warna teks dan kurangnya info bisa menyebabkan pengguna salah dalam memahami report. Tidak ada feedback selama user menunggu report; Hasil report tidak menjelaskan pasangan item yang dibandingkan. Program mampu mendeteksi ketidaksesuaian pada use case diagram dan sequence diagram dengan sangat baik. Hasil deteksi cukup akurat meski ada sedikit kasus yang kurang cocok dengan hasil yang sebenarnya.

Hasil isian untuk pertanyaan kedua, apakah Anda puas dengan hasil deteksi ketidaksesuaian yang dihasilkan oleh kakas bantu?, ditunjukkan oleh Tabel 5.19.

214 Tabel 5.19 Hasil pengisian kuesioner untuk pertanyaan keempat No

Nama Partisipan

Hasil Isian Saya puas. Cukup puas. Ya.

4

Reyhan Arief Dwika Setiawan Ahmad Ridwan Fauzi Adhi Nurilham

5 6 7

I Putu Pradnyana Daniel Henry M. Ardhinata Juari

8

Arif Fathur M.

9 10

Bekti Galan P. M. Husain Fuad D.

1 2 3

Deteksi ketidaksesuaian cukup dapat dipakai untuk memberikan prediksi ketidaksesuaian dalam diagram sequence. Hasil deteksi sudah cukup baik. Cukup puas. Puas dengan hasil dari kakas bantu ini karena akurasi deteksi bisa dibilang bagus, tetapi penyampaian hasil deteksi kurang menarik. Belum puas, karena mungkin ada ambiguitas saat merancang diagram. Puas. Secara umum, sudah puas untuk membantu mendeteksi ketidaksesuaiannya.

Hasil isian untuk pertanyaan kedua, Kritik dan saran Anda untuk perbaikan kakas bantu ke depannya?, ditunjukkan oleh Tabel 5.20.

Tabel 5.20 Hasil pengisian kuesioner untuk pertanyaan kelima No 1

Nama Partisipan

Hasil Isian

Reyhan Arief

Berikan feedback ketika program sedang memproses input.

215 Tabel 5.20 Hasil pengisian kuesioner untuk pertanyaan kelima (lanjutan) No

Nama Partisipan

Hasil Isian

2

Dwika Setiawan

3

Ahmad Ridwan Fauzi

4

Adhi Nurilham

5

I Putu Pradnyana

Sementara ini, kakas bantu hanya menampilkan kalimat mana yang tidak sesuai. Untuk ke depannya, akan lebih baik apabila ditambahkan alasan ketidaksesuaian untuk setiap ketidaksesuaian yang ditemukan. Selain itu tampilan kakas bantu juga bisa dikembangkan dengan menambahkan progress bar dan tampilan pesan kesalahan yang lebih baik. Tutorial singkat di awal apabila diperlukan agar kakas bantu dapat digunakan pada saat pertama kali dijalankan; Progress bar; Lebih baik apabila penyimpanan hasil daripada berbentuk opsi, lebih baik menggunakan tombol setelah hasil deteksi selesai dihitung untuk menghindari kesalahan pengguna. Kakas bantu dapat diperbaiki akurasinya dalam memberikan prediksi deteksi ketidaksesuaian. Hasil deteksi ketidaksesuaian mungkin dapat ditambahkan rekomendasi untuk memperbaiki.


Nama Partisipan

Hasil Isian

6

Daniel Henry

7

M. Ardhinata Juari

8

Arif Fathur M.

9

Bekti Galan P.

Kritik: (sudah ada pada jawaban pertanyaan pertama). saran: Menggunakan bahasa/istilah yang mudah dipahami orang awam. Jika tidak bisa, setidaknya diberi penjelasan singkat mengenai istilah tersebut; Menampilkan log pada kotak text tersendiri; Tombol ”Lakukan deteksi” didisable ketika proses pendeteksian sedang berjalan; Diberi keterangan makna tulisan warna hijau dan warna merah; Tampilan hasil dibuat berpasang-pasangan (kalimat use case description dengan triplet sequence diagram yang sesuai, kalimat use case description yang tidak sesuai dipasangkan dengan kotak kosong, triplet sequence diagram yang tidak sesuai juga dipasangkan dengan kotak kosong) agar lebih mudah dipahami. User experience kakas bantu ditingkatkan supaya pengguna merasa lebih nyaman dan efektif dalam menggunakan kakas bantu. Tambahkan feedback saat user menunggu hasil report. UI lebih diperbaiki; Performa ditingkatkan, sehingga kinerjanya tak begitu lama; Disediakan user manual atau help sehingga orang awam mampu menggunakannya dengan mudah; Semoga program ini dapat digunakan untuk praktisi IT, sehingga manfaatnya dapat dirasakan orang banyak.


Nama Partisipan

Hasil Isian

10

M. Husain Fuad D.

Pemberian informasi pemuatan proses yang dijalankan untuk memberi informasi pengguna bahwa aplikasi berjalan seperti semestinya.

5.4 Evaluasi Pengujian Subbab ini menjelaskan analisis dan evaluasi dari skenario pengujian yang telah dilakukan sebelumnya. Analisis dan evaluasi dari skenario pengujian yang telah dilakukan dijelaskan sebagai berikut.

5.4.1 Evaluasi Pengujian Hasil Deteksi Ketidaksesuaian Pengujian hasil deteksi ketidaksesuaian yang telah dilakukan terdiri dari dua skenario, yaitu pengujian hasil deteksi ketidaksesuaian sesuai teori pembuatan sequence diagram dan pengujian hasil deteksi ketidaksesuaian antara kakas bantu dan ahli. Berdasarkan hasil pengujian deteksi ketidaksesuaian sesuai teori pembuatan sequence diagram, kakas bantu yang dibuat dapat mendeteksi ketidaksesuaian diagram urutan dengan diagram kasus penggunaan. Hal tersebut ditunjukkan oleh hasil deteksi ketidaksesuaian yang didapat dengan menggunakan tiga perlakuan. Tiga perlakukan yang dimaksud, antara lain alur kejadian pada deskripsi kasus penggunaan tidak diubah urutannya, salah satu alur kejadian pada deskripsi kasus penggunaan dibalik urutannya, dan salah satu alur kejadian pada deskripsi kasus penggunaan dihilangkan. Untuk pengujian hasil deteksi ketidaksesuaian antara kakas bantu dan ahli, nilai kesepakatan tertinggi terjadi pada kasus Community Peace Program dengan nilai sempurna, yaitu 1,00. Hal tersebut terjadi karena pada kasus tersebut alur kejadian yang ada pada deskripsi kasus penggunaan sangat identik dengan diagram urutannya. Nilai kesepakatan kemudian turun menjadi 0,94 dan 0,97 untuk kasus ARENA, 0,74 untuk kasus ATM, dan 0,74 dan 0,68 untuk kasus Simple Address Book. Nilai kesepakatan

218 pada kedua kasus tersebut menunjukkan bahwa ada perbedaan kesepakatan antara kakas bantu dan ahli. Perbedaan nilai kesepakatan untuk kasus ARENA tidak terlalu signifikan dari nilai kesepakatan tertinggi. Namun, nilai perbedaan untuk kasus ATM dan Simple Address Book berbeda jauh. Perbedaan tersebut terjadi karena perbedaan penilaian kesesuaian. Kalimat deskripsi kasus penggunaan “The system asks to enter amount of money in the cash dispenser.” dan triplet {ATM, getInitialCash(), OperatorPanel} pada kasus penggunaan “System Startup” diberikan nilai tidak sesuai oleh kakas bantu, sedangkan kedua ahli memberikan nilai sesuai. Nilai kemiripan pasangan tersebut adalah 0,34 yang mana tidak memenuhi ambang batas yang telah ditentukan. Nilai ini berasal dari nilai cosine similarity kata benda yang tinggi (0,72), tetapi tidak ada kemiripan untuk kata kerja. Kata kerja “ask”, “enter”, dan “get” tidak memiliki kemiripan satu sama lain. Hal yang sama juga terjadi pada kasus Simple Address Book. Pasangan kalimat “The system displays a dialog box” dan triplet {AddressBookController, showMultiInputDialog(), MultiInput Pane} pada kasus penggunaan “Edit a Person” memiliki nilai cosine similarity kata benda yang tinggi (0,65), tetapi tidak ada nilai kemiripan untuk kata kerja. Selain itu, perbedaan nilai terjadi pada pasangan kalimat “The user highlights a name in the main window” dan triplet {User, doEdit(), AddressBookGUI}. Kakas bantu memberikan nilai sesuai, sedangkan kedua ahli memberikan nilai tidak sesuai. Kakas bantu memberikan nilai sesuai disebabkan nilai kemiripan kata kerja “highlight” dan “do” yang tinggi (0,80). Untuk kasus penggunaan “Sort Entries by Name”, pasangan kalimat “The user clicks the sort by name button in the main window.” dengan triplet {User, doSortByName, AddressBookGUI} dinilai tidak sesuai oleh kakas bantu dan sesuai oleh kedua ahli. Hal ini disebabkan oleh nilai cosine similarity kata benda yang tinggi (0,69), namun tidak ada kemiripan untuk kata kerja. Selanjutnya, nilai kesepakatan hasil deteksi ketidaksesuaian terendah antara kakas bantu dan ahli terjadi pada kasus Online Shopping System dan Emergency Monitoring System. Perbedaan penilaian kasus Online Shopping System saat menilai pasangan kalimat “System displays order information to customer.” dan triplet {CustomerCoordinator, orderConfirmation, CustomerInteraction}. Pasangan tersebut memiliki nilai kemiripan 0,34). Nilai tersebut berasal dari nilai cosine similarity kata benda yang tinggi (0,72) dan kata kerja yang sangat rendah (0,00). Kata kerja

219 “display” dan “order” tidak memiliki kemiripan pada pasangan tersebut. Selain itu, message “orderInformation” pada triplet tersebut sebenarnya adalah sebuah reply message dari sistem. Nama reply message biasanya berupa frasa kata benda. Karena kakas bantu tidak memanipulasi nama reply message saat mengubah triplet menjadi kalimat, kata “order” pada message tersebut ditandai sebagai kata kerja saat POS tagging kalimat. Perbedaan kesepakatan untuk kasus Emergency Monitoring System terletak pada pasangan kalimat “The monitoring operator requests to view the outstanding alarms.” dan triplet {MonitoringOperator, request(), OperatorInteraction}. Pasangan tersebut terlihat sangat mirip, tetapi memiliki nilai kemiripan yang rendah, yaitu 0,36. Sama seperti kasus sebelumnya, nilai tersebut berasal dari nilai cosine similarity kata benda yang tinggi (0,74), namun kata kerja tidak ada kemiripan. Nilai rendah tersebut terjadi karena hasil POS tagging kalimat yang salah. Kata “request” pada kalimat deskripsi kasus penggunaan pasangan tersebut ditandai sebagai kata benda. Padahal, kata “request” pada kalimat tersebut seharusnya adalah kata kerja. Hal ini menyebabkan tidak ada nilai kemiripan antara kata “request” pada kalimat deskripsi kasus penggunaan dan triplet. Apabila semua kasus dihitung secara keseluruhan, nilai kesepakatan tertinggi hasil deteksi ketidaksesuaian antara kakas bantu dan ahli didapatkan sejumlah 0,85. Nilai tersebut termasuk dalam kategori almost perfect menurut skala Landis dan Koch.

5.4.2 Evaluasi Pengujian Fungsional Hasil pengujian fungsional dirangkum oleh Tabel 5.21. Semua skenario pengujian fungsional berhasil berdasarkan tabel tersebut. Sehingga bisa ditarik kesimpulan, fungsionalitas dari kakas bantu yang dibuat telah sesuai dengan hasil yang diharapkan.

Tabel 5.21 Hasil pengujian fungsional Nama Fitur yang Diuji

Skenario

Hasil

Fitur Memeriksa Ketidaksesuaian Dokumen Rancangan

Skenario 1

Berhasil

Skenario 2

Berhasil

Fitur Mengekspor Laporan Hasil Pemeriksaaan Ketidaksesuaian

Skenario 1

Berhasil

220 Tabel 5.21 Hasil pengujian fungsional (lanjutan) Nama Fitur yang Diuji

5.4.3

Skenario

Hasil

Skenario 2

Berhasil

Evaluasi Pengujian Non-fungsional

Pengujian non-fungsional berfokus pada aspek usability. Analisis hasil pengujian ini didasarkan pada hasil isian kuesioner berupa pernyataan karena kuesioner berupa pertanyaan berisi pendapat dan saran mengenai kakas bantu. Nilai masing-masing pernyataan dikelompokkan ke dalam kategori sangat tidak setuju, tidak setuju, netral, setuju, dan sangat setuju. Karena nilai yang didapat berada di antara 0 sampai dengan 100, masing-masing kategori dibedakan dengan selisih nilai 20. Kategori tersebut ditunjukkan oleh Tabel 5.22.

Tabel 5.22 Kategori nilai pernyataan usability Skala Nilai 0% – 19,9% 20% – 39,9% 40% – 59,9% 60% – 79,9% 80% – 100%

Keterangan Sangat tidak setuju Tidak setuju Netral Setuju Sangat setuju

Secara garis besar, kakas bantu yang dibuat mudah untuk digunakan dan dipelajari oleh pengguna. Hal tersebut ditunjukkan oleh nilai pernyataan “Kakas bantu mudah digunakan.” dan “Kakas bantu dapat dipelajari dalam waktu kurang dari 5 menit.”. Kedua pernyataan tersebut dinilai setuju oleh partisipan. Namun, nilai pernyataan “Kakas bantu dapat dipelajari dalam waktu kurang dari 5 menit.” memiliki perbedaan nilai yang jauh dengan nilai pernyatan “Kakas bantu dapat digunakan tanpa bantuan orang atau instruksi tertulis”. Hal tersebut terjadi karena partisipan telah diberikan penjelasan dan arahan kakas bantu sebelum digunakan. Partisipan berpikir apabila tidak ada instruksi atau arahan sebelumnya akan

221 menyebabkan kesulitan penggunaan kakas bantu. Hal ini bisa dilihat dari hasil isian kuesioner pertanyaan. Partisipan memberikan saran berupa penambahan menu help atau teks pembantu. Namun, partisipan setuju jika informasi atau nama perintah yang ada di kakas bantu mudah untuk dipahami. Nilai netral diberikan pada pernyataan “Kakas bantu menyediakan respon atau pesan kesalahan yang jelas.”. Ini terjadi karena ada partisipan yang melakukan kesalahan dan ada yang tidak saat melakukan penggunaan kakas bantu. Selain itu, bisa dilihat dari hasil isian kuesioner pertanyaan, banyak partisipan memberikan saran berupa feedback atau respon ketika melakukan perintah, seperti log atau progres deteksi ketidaksesuaian.


BAB VI KESIMPULAN DAN SARAN

Bab ini berisi kesimpulan yang diperoleh dari pengerjaan Tugas Akhir dan hasil pengujian yang telah dilakukan. Selain itu, terdapat saran yang diharapkan agar untuk mengembangkan hasil Tugas Akhir ini lebih baik lagi.

6.1 Kesimpulan Selama proses pengerjaan Tugas Akhir ini, mulai dari tahap analisis, perancangan, implementasi, hingga pengujian sistem, didapatkan kesimpulan sebagai berikut: 1. Kakas bantu yang dibuat berhasil memenuhi tujuan utamanya untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram). 2. Berdasarkan nilai kappa statistic yang didapatkan dari pengujian, hasil deteksi ketidaksesuaian yang dihasilkan oleh kakas bantu menghasilkan kesepakatan dengan ahli sejumlah 0,85. Nilai ini menunjukkan kesepakatan antara kakas bantu dan ahli rekayasa perangkat lunak yang tinggi. 3. Kakas bantu yang dibuat dinilai setuju oleh partisipan untuk aspek kemudahan mempelajari dan menggunakan.

6.2 Saran Berikut adalah saran untuk pengembangan kakas bantu yang telah dibuat di masa yang akan datang: 1. Mengeksplorasi lebih jauh mengenai pembentukan triplet menjadi kalimat terkait jenis message, seperti reply dan create message. 2. Menerapkan kakas bantu ke banyak sistem atau proyek perangkat lunak untuk mengetahui seberapa valid teknik deteksi ketidaksesuaian. 3. Kakas bantu yang dibuat terbatas untuk membaca alur kejadian dasar (basic flow) kasus penggunaan. Ke depan, kakas bantu diharapkan dapat mengangani alur alternatif pada kasus penggunaan. 4. Menambahkan feedback atau log ketika proses deteksi ketidaksesuaian sedang dilakukan.

223

224 5. Menambahkan menu help yang berisi instruksi tertulis atau user manual yang menjelaskan apa dan bagaimana proses kerja kakas bantu.

LAMPIRAN A SPESIFIKASI KASUS PENGGUNAAN

Setiap kasus penggunaan yang telah dijabarkan sebelumnya kemudian dideskripsikan secara rinci ke dalam spesifikasi kasus penggunaan (use case specification). Spesifikasi kasus penggunaan di bawah ini mengacu pada sebuah template yang disediakan oleh Rational Unified Process (RUP).

A.1 Spesifikasi Kasus Penggunaan: Memeriksa Ketidaksesuaian Dokumen Rancangan

Gambar A.1 Kasus penggunaan (use case) “Memeriksa Ketidaksesuaian Dokumen Rancangan” 1. Memeriksa Ketidaksesuaian Dokumen Rancangan 1.1. Deskripsi Singkat Kasus penggunaan ini mendeskripsikan bagaimana analis sistem melakukan pemeriksaan dokumen rancangan. 2. Alur Kejadian 2.1. Alur Dasar 1. Analis sistem menekan tombol “Masukan berkas...” pada layar utama kakas utama. 2. Kakas bantu menampilkan jendela “Masukan berkas dokumen rancangan” untuk memilih lokasi di mana dokumen rancangan disimpan. 3. Analis sistem memilih dokumen rancangan pada lokasi di mana dokumen rancangan disimpan.

225

226

3. 4.

5.

6.

4. Analis sistem menekan tombol “Open” pada jendela “Masukan berkas dokumen rancangan”. 5. Kakas bantu menampilkan lokasi dokumen rancangan yang telah dipilih pada kolom masukan berkas. 6. Analis sistem menekan tombol “Lakukan deteksi” pada layar utama kakas bantu. 7. Kakas bantu menampilkan hasil deteksi ketidaksesuaian pada layar utama kakas bantu. 2.2. Alur Alternatif Kasus penggunaan ini tidak memiliki alur alternatif. 2.3. Alur Eksepsional Jika pada langkah 4 alur dasar, analis sistem salah memasukkan format dokumen rancangan maka: 4.1a Sistem menampilkan pesan jika format dokumen rancangan yang dimasukkan tidak sesuai. 4.1a.1 Sistem menampilkan pesan kesalahan. 4.1a.2 Kasus penggunaan berhenti. Kebutuhan Khusus Kasus penggunaan ini tidak memiliki kebutuhan khusus. Prakondisi 4.1. Analis sistem memiliki dokumen rancangan yang belum diperiksa. Pasca-kondisi 5.1. Analis sistem mendapatkan hasil deteksi ketidaksesuaian dokumen rancangan (ketidaksesuaian ditemukan atau tidak ditemukan). Titik Ekstensi Pada sub-kasus penggunaan mengekspor laporan hasil pemeriksaan ketidaksesuaian: 4a. Analis sistem dapat memilih opsi untuk mengekspor hasil pemeriksaan ketidaksesuaian ke dalam sebuah laporan. 4a.1 Analis sistem mencentang opsi “Ekspor hasil pemeriksaan ketidaksesuaian ke dalam laporan” pada layar utama kakas bantu. 4a.2 Analis sistem menekan tombol “Simpan hasil...”. 4a.3 Kakas bantu menampilkan jendela untuk memilih lokasi di mana laporan hasil pemeriksaan ketidaksesuaian akan disimpan. 4a.4 Analis sistem memilih lokasi penyimpanan laporan hasil

227 pemeriksaan ketidaksesuaian. 4a.5 Analis sistem memilih jenis format laporan hasil deteksi ketidaksesuaian rancangan. 4a.6 Analis sistem memasukkan nama berkas laporan hasil pemeriksaan ketidaksesuaian. 4a.7 Analis sistem menekan tombol “Save”. 4a.8 Kakas bantu menampilkan lokasi penyimpanan hasil deteksi pada layar utama kakas bantu.


LAMPIRAN B DATA PENGUJIAN

Dokumen rancangan yang digunakan untuk data uji coba kakas bantu untuk mendeteksi ketidaksesuaian diagram urutan (sequence diagram) dengan diagram kasus penggunaan (use case diagram) sudah sesuai dengan aturan pembuatan dokumen rancangan. Dokumen rancangan tersebut berisi sistem-sistem berikut ini:

B.1 ARENA ARENA adalah sebuah sistem berbasis web yang digunakan untuk mengatur dan mengadakan pertandingan. Penyelenggara dapat membuat pertandingan baru, menggunggahnya ke server, dan mengumumkan pertandingan tersebut ke pemain-pemain yang ada di internet. Data dari sistem ini diambil dari buku Object-Oriented Software Engineering Using UML, Patterns, and Java, 3rd edition, halaman 207 dan 213 dan dokumen proyek pada laman https://wwwbruegge.in.tum.de/arena02/doc/ RAD/RAD.html. Lima buah kasus penggunaan (use case) diambil dari sistem ini. Kasus penggunaan tersebut antara lain: 1. Announce Tournament

Gambar B.1 Diagram kasus penggunaan (use case diagram) ARENA “Announce Tournament” 229

230

Gambar B.2 Diagram urutan (sequence diagram) ARENA “Announce Tournament” 2. Chat with Players

Gambar B.3 Diagram kasus penggunaan (use case diagram) ARENA “Chat with Players”

231

Gambar B.4 Diagram urutan (sequence diagram) ARENA “Chat with Players”

3. Drop Item

Gambar B.5 Diagram kasus penggunaan (use case diagram) ARENA “Drop Item”

232

Gambar B.6 Diagram urutan (sequence diagram) ARENA “Drop Item”

4. Look at Item

Gambar B.7 Diagram kasus penggunaan (use case diagram) ARENA “Look at Item”

233

Gambar B.8 Diagram urutan (sequence diagram) ARENA “Look at Item”

5. Move

Gambar B.9 Diagram kasus penggunaan (use case diagram) ARENA “Move”

234

Gambar B.10 Diagram urutan (sequence diagram) ARENA “Move”

B.2

ATM

ATM (automated teller machine) adalah sebuah sistem yang memiliki tempat untuk membaca kartu ATM, console (keyboard dan layar) agar nasabah dapat berinteraksi, tempat keluarnya uang, mesin cetak bukti transaksi, dan tombol yang digunakan operator untuk menjalankan atau memberhentikan mesin. Data dari sistem ini diambil dari laman http: //www.math-cs.gordon.edu/courses/cs211/ATMExample/. Kasus penggunaan yang diambil antara lain: 1. System Startup

Gambar B.11 Diagram kasus penggunaan (use case diagram) ATM “System Startup”

235

Gambar B.12 Diagram urutan (sequence diagram) ATM “System Startup”

2. System Shutdown

Gambar B.13 Diagram kasus penggunaan (use case diagram) ATM “System Shutdown”

236

Gambar B.14 Diagram urutan (sequence diagram) ATM “System Shutdown”

B.3

Simple Address Book

Simple Address Book adalah sebuah sistem yang dirancang untuk mengatur buku alamat. Buku ini dapat menyimpan nama, alamat, nomor telepon, dan sebagainya Selain itu, buku juga menyimpan kota, provinsi, dan kode pos. Data sistem ini diambil dari laman http://www.cs. gordon.edu/courses/cs211/AddressBookExample/. Kasus penggunaan yang diambil antara lain: 1. Edit a Person

Gambar B.15 Diagram kasus penggunaan (use case diagram) Simple Address Book “Edit a Person”

237

Gambar B.16 Diagram urutan (sequence diagram) Simple Address Book “Edit a Person”

2. Sort Entries by Name

238

Gambar B.17 Diagram kasus penggunaan (use case diagram) Simple Address Book “Sort Entries by Name”

Gambar B.18 Diagram urutan (sequence diagram) Simple Address Book “Sort Entries by Name”

239

B.4 Online Shopping System Online Shopping System adalah sebuah sistem informasi yang memudahkan pelanggan untuk melakukan transaksi pembelian barang secara online. Data dari sistem ini diambil dari buku Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures, 1st edition, halaman 424. Kasus penggunaan yang diambil hanya satu, yaitu “Make Order Request”.

Gambar B.19 Diagram kasus penggunaan (use case diagram) Online Shopping System “Make Order Request”

Gambar B.20 Diagram urutan (sequence diagram) Online Shopping System “Make Order Request”

240

B.5

Emergency Monitoring System

Emergency Monitoring System adalah sebuah sistem yang digunakan untuk memantau keadaan darurat. Sistem ini mengintegrasikan komponen perangkat keras, seperti alarm. Data dari sistem ini diambil dari buku Software Modeling & Design: UML, Use Cases, Patterns, & Software Architectures, 1st edition, halaman 453. Kasus penggunaan yang diambil hanya satu, yaitu “View Alarms”.

Gambar B.21 Diagram kasus penggunaan (use case diagram) Emergency Monitoring System “View Alarms”

Gambar B.22 Diagram urutan (sequence diagram) Emergency Monitoring System “View Alarms”

241

B.6 Community Peace Program Community Peace Program merupakan sebuah proyek yang diambil dari buku UML for the IT Business Analyst: A Practical Guide to Requirements Gathering Using the Unified Modeling Language, 2nd edition, halaman 302-303. Kasus penggunaan yang diambil dari proyek ini hanya satu, yaitu “Disburse Payments”.

Gambar B.23 Diagram kasus penggunaan (use case diagram) Community Peace Program “Disburse Payments”

Gambar B.24 Diagram urutan (sequence diagram) Community Peace Progam “Disburse Payments”


DAFTAR PUSTAKA

[1] Siahaan, D. 2012. Analisa Kebutuhan dalam Rekayasa Perangkat Lunak. Yogyakarta: Penerbit ANDI. [2] MKLab. 2014. StarUML. , diakses 10 November 2015. [3] StarUML. 2014. XMI extension for StarUML 2. , diakses 22 November 2015. [4] Object Management Group. 1997. Unified Modeling Language (UML). , diakses 22 November 2015. [5] Sapna, P. G. dan Mohanty, H. 2007. “Ensuring Consistency in Relational Repository Models”. 10th International Conference on Information Technology (ICIT 2007), pp. 217-222. [6] Bruegge, B. dan Dutoit, A. H. 2010. Object-Oriented Software Engineering Using UML, Patterns, and Java. Pearson Prentice Hall. [7] Object Management Group. 2000. Metadata Interchange (XMI) Specification. , diakses 22 November 2015. [8] Object Management Group. 1997. About the Object Management Group. , diakses 22 November 2015. [9] Ruíz, F., Vizcaíno, A., García, F., dan Piattini, M. 2003. “Using XMI and MOF for Representation and Interchange of Software Processes”. Proceedings of the 14th International Workshop on Database and Expert Systems Applications. DEXA ’03. [10] StarUML. 2005. The Open Source UML/MDA Platform. , diakses 1 Desember 2015. [11] Santorini, B. 1990. “Part-of-speech tagging guidelines for the Penn Treebank Project (3rd revision)”. [12] Manning, Christopher D., Surdeanu, M., Bauer, J., Finkel, J., Bethard, Steven J., dan McClosky, D. 2014. “The Stanford CoreNLP Natural Language Processing Toolkit”. Proceedings of 52nd Annual Meeting of the Association for Computational Linguistics: System Demonstrations, pp. 55-60. [13] Li, Y., McLean, D., Bandar, Z. A., O’Shea, J. D., dan Crockett, K. 2006. “Sentence Similarity Based on Semantic Nets and Corpus Sta-

243

244

[14]

[15]

[16] [17]

[18]

[19]

[20]

[21] [22]

[23]

[24]

[25]

tistics”. IEEE Transactions on Knowledge and Data Engineering, Vol. 18, No. 8, pp. 1138-1150. Lee, M. C. 2011. “A Novel Sentence Similarity Measure for Semantic-based Expert Systems”. Expert System Application, Vol. 38, No. 5, pp. 6392-6399. Mihalcea, R., Corley, C., dan Strapparava, C. 2006. “Corpus-based and Knowledge-based Measures of Text Similarity”. Proceedings of American Association for Artificial Intelligence, Boston, pp. 775780. Fellbaum, C. 1998. WordNet: An Electronic Lexical Database. Cambridge, MA: MIT Press. Gomaa, W. H. dan Fahmy, A. A. 2013. “A Survey of Text Similarity Approaches”. International Journal of Computer Applications, Vol. 68, No. 13, pp. 13-18. Patwardhan, S. Banerjee, S., dan Pedersen, T. 2003. “Using Measures of Semantic Relatedness for Word Sense Disambiguation”. International Conference on Intelligent Text Processing and Computational Linguistics, pp.241-257. Leacock, C. dan Chodorow, M. 1998. “Combining Local Context and WordNet Sense Similarity for Word Sense Identification”. WordNet, An Electronic Lexical Database, pp. 265-283. Wu, Z. dan Palmer, M. 1994. “Verbs Semantics and Lexical Selection”. Proceedings of the 32nd Annual Meeting on Association for Computational Linguistics, pp. 133-138. Resnik, P. 1995. “Using Information Content to Evaluate Semantic Similarity in a Taxonomy”. arXiv preprint cmp-lg/9511007. Seco, N., Veale, T., dan Hayes, J. 2004. “An Intrinsic Information content metric for semantic similarity in WordNet”. European Conference on Artificial Intelligence (ECAI), Vol. 16, pp. 1089. Zhou, Z., Wang, Y., dan Gu, J. 2008. “A New Model of Information Content for Semantic Similarity in WordNet”. Future Generation Communication and Networking Symposia, Vol. 3, IEEE, pp. 85-89. Sánchez, D., Batet, M., dan Isern, D. 2011. “Ontology-based Information Content Computation”. Knowledge-Based Systems, Vol. 24, No. 2, pp. 297-303. Meng, L. dan Gu, J. 2012. “A New Model for Measuring Word Sense Similarity in WordNet”. Proceedings of the 4th International Conference on Advanced Communication and Networking, pp. 18-23.

245 [26] Lin, D. 1998. “An Information-theoretic Definition of Similarity”. ICML, Vol. 98, pp. 296-304. [27] Jiang, J. J. dan Conrath, D. W. 1997. “Semantic Similarity Based on Corpus Statistics and Lexical Taxonomy”. arXiv preprint cmplg/9709008. [28] Atoum, I., Otoom, A., dan Kulathuramaiyer, N. “A Comprehensive Comparative Study of Word and Sentence Similarity Measures. 2016. International Journal of Computer Applications, Vol. 135, No. 1, pp. 10-17. [29] Lastra-Díaz, J. J. dan García-Serrano, A. 2015. “A novel family of IC-based similarity measures with a detailed experimental survey on WordNet”. Engineering Applications of Artificial Intelligence, Vol. 46, pp. 140-153. [30] Harispe, S., Ranwez, S., Janaqi, S., dan Montmain, J. 2014. “The Semantic Measures Library and Toolkit: Fast Computation of Semantic Similarity and Relatedness Using Biomedical Ontologies”. Bioinformatics, Vol. 30, No. 5, pp. 740-742. [31] Howe, D. C. 2009. “RiTa: Creativity Support for Computational Literature”. Proceedings of the 7th ACM Conference on Creativity Recognition (C&C ’09), pp. 205-210. [32] Choi, J. D., dan Palmer, M. 2012. “Fast and robust part-of-speech tagging using dynamic model selection”. Proceedings of the 50th Annual Meeting of the Association for Computational Linguistics: Short Papers-Volume 2, pp. 363-367. [33] Apache Software Foundation. 2002. Apache POI - the Java API for Microsoft Documents. , diakses 20 Oktober 2016. [34] iText Software Corp. 2000. Core Java Library + PDF/A, xtra and XML Worker. , diakses 20 Oktober 2016. [35] Gwet, K. 2002. “Kappa statistic is not satisfactory for assessing the extent of agreement between raters”. Statistical methods for interrater reliability assessment, No. 1, Vol. 6, pp. 1-6. [36] Landis, J. R. dan Koch, G. G. 1977. “The measurement of observer agreement for categorical data”. biometrics, pp. 159-174.


BIODATA PENULIS

Andrias Meisyal Yuwantoko merupakan anak dari pasangan Bapak Suwanto dan Ibu Yatimah. Lahir di Madiun pada tanggal 16 Mei 1993. Penulis merupakan anak sulung dari tiga bersaudara. Penulis menempuh pendidikan formal dimulai dari SDN 01 Demangan Madiun (2002-2008), SMPN 4 Madiun (2005-2008), SMAN 1 Madiun (20082011), dan sarjana (S1) Teknik Informatika ITS Surabaya (2012-2017). Penulis mengambil rumpun mata kuliah (RMK) Rekayasa Perangkat Lunak untuk menyelesaikan pendidikan sarjana (S1). Selama kuliah, penulis aktif dalam organisasi Himpunan Mahasiswa Teknik Computer-Informatika ITS (2013-2014). Penulis juga terlibat dalam kegiatan kepantian SCHEMATICS 2013. Selain itu, penulis juga memiliki pengalaman menjadi asisten pengajar untuk mata kuliah Aljabar Linear dan Basis Data. Penulis hobi membaca, bersepeda, dan mempelajari hal baru. Penulis dapat dihubungi melalui email [email protected] atau [email protected].

247

PEMBUATAN KAKAS BANTU UNTUK MENDETEKSI KETIDAKSESUAIAN DIAGRAM URUTAN (SEQUENCE DIAGRAM) DENGAN DIAGRAM KASUS PENGGUNAAN (USE CASE DIAGRAM)

Recommend Documents