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
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
ii
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
DIAGRAM) DENGAN DIAGRAM KASUS PENGGUNAAN
(USE CASE DIAGRAM)
Nama : ANDRIAS MEISYAL YUWANTOKO
NRP : 5112100116
Jurusan : Teknik Informatika FTIf -ITS
Pembimbing I : Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng.
Pembimbing II : Adhatus Solichah Ahmadiyah, S.Kom., M.Sc.
Abstrak
Siklus hidup pengembangan perangkat lunak membagi aktivi- tas pengembangan ke dalam tahap merencanakan, menganalisis, merancang, mengimplementasikan, dan merawat perangkat lunak.
Analis sistem memiliki peranan penting untuk menganalisis kebu- tuhan pengguna. Dalam pengembangan perangkat lunak berorien- tasi objek, analisis dan perancangan sistem mengacu kepada baha- sa unified modeling language (UML). Analis sistem menerjemah- kan kebutuhan tersebut dengan merancang diagram UML. Salah satu diagram yang dirancang adalah diagram urutan (sequence di- agram).
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 sesu- ai 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 ketidaksesu-
vii
bila sebuah proyek perangkat lunak memiliki banyak rancangan di- agram, tetapi sumber daya analis sistem tidak mencukupi. Analis sistem membutuhkan waktu yang lama untuk memeriksa rancangan diagram.
Pembuatan kakas bantu untuk mendeteksi ketidaksesuaian ke- dua diagram tersebut sangat diperlukan. Kakas bantu yang dibuat mengimplementasikan pemrosesan bahasa alami. Pemrosesan ba- hasa alami yang digunakan adalah perhitungan kemiripan seman- tik kalimat. Pendeteksian ketidaksesuaian dilakukan dengan mela- kukan ekstraksi kalimat alur kejadian pada deskripsi kasus peng- gunaan dan triplet yang berisi aktor, message, boundary class atau boundary class, message, control class pada diagram urutan. Ke- tidaksesuaian dilihat dari nilai perhitungan kemiripan kalimat an- tara kalimat alur kejadian dan triplet yang melewati ambang batas yang telah ditentukan. Hasil pendeteksian dinyatakan dalam se- buah daftar yang berisi kalimat alur kejadian dan triplet dengan penanda “Sesuai” atau “Tidak sesuai”. Dari hasil percobaan, ka- kas bantu yang dibuat dapat mendeteksi ketidaksesuaian antara di- agram urutan dan diagram kasus penggunaan. Nilai kesepakatan hasil deteksi ketidaksesuaian dengan ahli rekayasa perangkat lu- nak melalui kappa statistic didapatkan sejumlah 0,85. Sehingga dari hasil tersebut, kakas bantu ini diharapkan tidak hanya mem- bantu analis sistem menghasilkan rancangan diagram yang sesuai akan tetapi mempercepat waktu pengembangan perangkat lunak.
Kata kunci: diagram urutan, diagram kasus penggunaan, keti- daksesuaian, pemrosesan bahasa alami, kemiripan semantik ka- limat.
viii
DIAGRAM
Name : ANDRIAS MEISYAL YUWANTOKO
NRP : 5112100116
Major : Informatics FTIf -ITS
Supervisor I : Daniel Oranova Siahaan, S.Kom., M.Sc., P.D.Eng.
Supervisor II : Adhatus Solichah Ahmadiyah, S.Kom., M.Sc.
Abstract
Software development life cycle divides the development activ- ities into planning, analysis, design, implementation, and mainte- nance phases. System analyst has an important role to analyze the user needs. In object-oriented software development, system analy- sis and design refers to the unified modeling language (UML). Sys- tem 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 de- fined whether flows of interaction in the use case description are in accordance with the sequence of messages sent by actor to bound- ary class or system to boundary class. Ensuring consistency of di- agram gives impact to correct implementation of system. However, this examination is still done manually. Problems arise if a proj- ect 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
ed 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. Inconsisten- cy is detected from the calculation of sentence similarity between a flow of events and a triplet that exceeded preset threshold. Detec- tion results are represented in a list that contains flow of events and triplets with “Sesuai” or “Tidak sesuai” as a label. From the expe- rimental result, this tool can detect inconsistency between sequen- ce diagram and use case diagram. The inconsistency detection re- sult 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 de- velopment.
Keywords: sequence diagram, use case diagram, inconsistency, natural language processing, sentence semantic similarity.
x
Õæk QË @ á Ô g QË@ é <Ë@ Õ æ .
Alhamdulillahirabbil’alamin, segala puji bagi Allah SWT yang telah melimpahkan rahmat dan hidayah-Nya sehingga penulis da- pat menyelesaikan Tugas Akhir yang berjudul “Pembuatan Kakas Bantu untuk Mendeteksi Ketidaksesuaian Diagram (Sequence
Diagram) dengan Diagram Kasus Penggunaan (Use Case Dia- gram)”. Tugas Akhir ini disusun sebagai persyaratan untuk menye-lesaikan Program Sarjana (S1) Jurusan Teknik Informatika Institut Teknologi Sepuluh Nopember Surabaya.
Tugas Akhir ini dapat selesai tidak lepas dari bantuan dan du- kungan 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., sela- ku pembimbing I yang telah meluangkan waktu untuk memban- tu, membimbing, dan memotivasi penulis dalam menyelesaikan Tugas Akhir.
3. Ibu Adhatus Solichah Ahmadiyah, S.Kom., M.Sc., selaku pem- bimbing II yang juga telah meluangkan waktu untuk membantu, membimbing, dan memotivasi penulis dalam menyelesaikan Tu- gas 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 jurus- an 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
6. Teman-teman angkatan 2012 yang telah membantu, membagi- kan ilmu, menjaga kebersamaan, dan memberikan motivasi ke- pada 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 ba- nyak 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
ABSTRAK vii
ABSTRACT ix
KATA PENGANTAR xi
DAFTAR ISI xiii
DAFTAR TABEL xix
DAFTAR GAMBAR xxiii
DAFTAR KODE SUMBER xxvii
BAB I PENDAHULUAN 1
1.1 Latar Belakang . . . . 1
1.2 Rumusan Masalah . . . . 3
1.3 Batasan Masalah . . . . 3
1.4 Tujuan . . . . 4
1.5 Manfaat . . . . 4
1.6 Metodologi . . . . 4
1.7 Sistematika Penulisan Laporan Tugas Akhir . . . . 7
BAB II TINJAUAN PUSTAKA 11 2.1 Diagram Kasus Penggunaan (Use Case Diagram) . 11 2.2 Deskripsi Kasus Penggunaan (Use Case Description) 14 2.3 Diagram Urutan (Sequence Diagram) . . . . 16
2.4 Ketidaksesuaian Diagram Urutan dan Diagram Ka- sus Penggunaan . . . . 20
2.5 XML Metadata Interchange (XMI) . . . . 21
2.6 StarUML . . . . 27
2.7 Pemrosesan Bahasa Alami (Natural Language Pro- cessing) . . . . 28
xiii
2.8.1 Kemiripan Semantik Kalimat (Sentence Se-
mantic Similarity) . . . . 35
2.8.2 Kemiripan Sintaksis Kalimat (Word Order Similarity) . . . . 37
2.8.3 Kombinasi Semantik dan Sintaksis Kalimat 38 2.9 WordNet . . . . 38
2.10 Perhitungan Kemiripan Kata . . . . 39
2.10.1 Leacock-Chodorow . . . . 41
2.10.2 Wu-Palmer . . . . 41
2.10.3 Path . . . . 41
2.10.4 Resnik . . . . 42
2.10.5 Lin . . . . 42
2.10.6 Jiang-Conrath . . . . 42
BAB III ANALISIS DAN PERANCANGAN SISTEM 45 3.1 Analisis Perangkat Lunak . . . . 45
3.1.1 Deskripsi Umum Perangkat Lunak . . . . . 45
3.1.2 Proses Bisnis . . . . 46
3.1.3 Fungsi Produk . . . . 47
3.1.4 Karakteristik Pengguna . . . . 47
3.1.5 Batasan . . . . 48
3.1.6 Kebutuhan Non-fungsional . . . . 48
3.1.7 Diagram Kasus Penggunaan . . . . 49
3.1.8 Diagram Aktivitas (Activity Diagram) . . . 51
3.1.8.1 Diagram Aktivitas: Memeriksa Ke- tidaksesuaian Dokumen Rancang- an . . . . 52
3.1.8.2 Diagram Aktivitas: Mengekspor Laporan Hasil Pemeriksaan Ke- tidaksesuaian . . . . 53
3.1.9 Kelas Analisis . . . . 54
xiv
3.1.9.2 Kelas Analisis Mengekspor La- poran Hasil Pemeriksaan Ketidak-
sesuaian . . . . 73
3.1.10 Diagram Urutan . . . . 88
3.2 Perancangan Perangkat Lunak . . . . 92
3.2.1 Perancangan Antarmuka . . . . 92
3.2.1.1 Antarmuka Utama . . . . 92
3.2.1.2 Jendela Masukan Berkas Doku- men Rancangan . . . . 93
3.2.1.3 Antarmuka Ekspor Hasil Peme- riksaan 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 Ran- cangan . . . . 98
3.2.2.2 Proses Memasukkan Dokumen Ran- cangan . . . 104
3.2.2.3 Proses Memilih Opsi Ekspor Ha- sil Deteksi Ketidaksesuaian . . . 105
3.2.2.4 Proses Mengekstraksi Dokumen Rancangan . . . 106
3.2.2.5 Proses Mendeteksi Ketidaksesu- aian . . . 115
3.2.2.6 Proses Menghitung Kemiripan Ka- limat Alur Kejadian Dasar (Basic Flow) dan Triplet . . . 118
3.2.2.7 Proses Menampilkan Hasil Detek- si Ketidaksesuaian . . . 123
3.2.2.8 Proses Mengekspor Hasil Detek- si dalam Bentuk Laporan . . . . 123 3.2.3 Perancangan Diagram Kelas (Class Diagram)124
xv
daksesuaian Dokumen Rancangan 124 3.2.3.2 Diagram Kelas Mengekspor La-
poran Hasil Pemeriksaan Ketidak- sesuaian . . . 149 3.2.3.3 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 Ber-
kas Dokumen Rancangan . . . . 161 4.2.1.3 Implementasi Antarmuka Ekspor
Hasil Pemeriksaan ke dalam La- poran . . . 161 4.2.1.4 Implementasi Jendela Simpan Hasil162 4.2.2 Implementasi Proses . . . 163
4.2.2.1 Implementasi Proses Mengekstrak- si Dokumen Rancangan . . . 163 4.2.2.2 Implementasi Proses Mendeteksi
Ketidaksesuaian . . . 165 4.2.2.3 Implementasi Proses Menghitung
Kemiripan Kalimat Alur Kejadi- an 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 La- poran . . . 180
BAB V PENGUJIAN DAN EVALUASI 187
5.1 Lingkungan Pengujian . . . 187
xvi
5.3.1 Pengujian Hasil Deteksi Ketidaksesuaian . 189 5.3.1.1 Pengujian Hasil Deteksi Ketidak-
sesuaian Kakas Bantu Sesuai Te- ori Pembuatan Sequence Diagram 191 5.3.1.2 Pengujian Hasil Deteksi Ketidak-
sesuaian antara Kakas Bantu dan Ahli . . . 194 5.3.2 Pengujian Fungsional . . . 200
5.3.2.1 Pengujian Fitur Memeriksa Keti- daksesuaian Dokumen Rancangan 201 5.3.2.2 Pengujian Fitur Mengekspor La-
poran Hasil Pemeriksaan Ketidak- sesuaian . . . 204 5.3.3 Pengujian Non-fungsional . . . 207 5.4 Evaluasi Pengujian . . . 217
5.4.1 Evaluasi Pengujian Hasil Deteksi Ketidak- sesuaian . . . 217 5.4.2 Evaluasi Pengujian Fungsional . . . 219 5.4.3 Evaluasi Pengujian Non-fungsional . . . . 220
BAB VI KESIMPULAN DAN SARAN 223
6.1 Kesimpulan . . . 223 6.2 Saran . . . 223 LAMPIRAN A SPESIFIKASI KASUS PENGGU-
NAAN 225
LAMPIRAN B DATA PENGUJIAN 229
DAFTAR PUSTAKA 243
BIODATA PENULIS 247
xvii
xviii
2.1 Komponen diagram kasus penggunaan . . . . 12 2.2 Komponen diagram urutan . . . . 17 2.3 Elemen penting XMI pada diagram kasus penggu-
naan dan diagram urutan . . . . 22 2.4 Model Penn Treebank bahasa Inggris . . . . 29 3.4 Kandidat kelas kasus penggunaan “Memeriksa Ke-
tidaksesuaian Dokumen Rancangan” . . . . 56 3.5 Pemetaan kandidat kelas kasus penggunaan “Me-
meriksa Ketidaksesuaian Dokumen Rancangan” . . 66 3.6 Tanggung jawab kelas pada kasus penggunaan “Me-
meriksa Ketidaksesuaian Dokumen Rancangan” . . 69 3.7 Atribut dan hubungan kelas pada kasus penggunaan
“Memeriksa Ketidaksesuaian Dokumen Rancangan” 72 3.8 Kandidat kelas kasus penggunaan “Mengekspor La-
poran Hasil Pemeriksaan Ketidaksesuaian” . . . . 75 3.9 Pemetaan kandidat kelas kasus penggunaan “Meng-
ekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” 82 3.10 Tanggung jawab kelas pada kasus penggunaan “Meng-
ekspor Laporan Hasil Pemeriksaan Ketidaksesuaian” 85 3.11 Atribut dan hubungan kelas pada kasus penggunaan
“Mengekspor Laporan Hasil Pemeriksaan Ketidak- sesuaian” . . . . 87 3.12 Spesifikasi atribut antarmuka utama kakas bantu . . 93 3.13 Spesifikasi atribut jendela masukan berkas doku-
men rancangan . . . . 94 3.14 Spesifikasi atribut antarmuka ekspor hasil pemerik-
saan ke dalam laporan . . . . 95 3.15 Spesifikasi atribut jendela simpan hasil . . . . 96 3.16 Pemetaan elemen diagram dengan elemen dokumen
rancangan (XMI) . . . 106
xix
ruang semantik kata benda . . . 121 3.18 Himpunan kata kerja kalimat pertama dibanding ru-
ang semantik kata kerja . . . 121 3.19 Atribut dan operasi kelas pada proses memasukkan
dokumen rancangan . . . 125 3.20 Atribut dan operasi kelas pada proses mengekstrak-
si dokumen rancangan . . . 128 3.21 Atribut dan operasi kelas pada proses mendeteksi
ketidaksesuaian . . . 136 3.22 Atribut dan operasi kelas pada proses menghitung
kemiripan kalimat alur kejadian dasar dan triplet . 143 3.23 Atribut dan operasi kelas pada proses menampilkan
hasil deteksi ketidaksesuaian . . . 145 3.24 Atribut dan operasi kelas pada proses memilih opsi
ekspor hasil deteksi ketidaksesuaian . . . 151 3.25 Atribut dan operasi kelas pada proses mengekspor
hasil deteksi dalam bentuk laporan . . . 153 3.26 Modul-modul di dalam kakas bantu . . . 156 5.1 Hasil sebuah percobaan . . . 189 5.2 Hasil deteksi ketidaksesuaian sistem “ARENA” an-
tara kakas bantu dengan ahli pertama . . . 195 5.3 Hasil deteksi ketidaksesuaian sistem “ARENA” an-
tara kakas bantu dengan ahli kedua . . . 195 5.4 Hasil deteksi ketidaksesuaian sistem “ATM” antara
kakas bantu dengan ahli pertama . . . 196 5.5 Hasil deteksi ketidaksesuaian sistem “Simple Address
Book” antara kakas bantu dengan ahli pertama . . . 197 5.6 Hasil deteksi ketidaksesuaian sistem “Simple Address
Book” antara kakas bantu dengan ahli kedua . . . . 197 5.7 Hasil deteksi ketidaksesuaian sistem “Online Shop-
ping System” antara kakas bantu dengan ahli pertama198
xx
pertama . . . 198 5.9 Hasil deteksi ketidaksesuaian sistem “Community
Peace Program” antara kakas bantu dengan ahli per- tama . . . 199 5.10 Nilai kappa statistic setiap kasus uji . . . 200 5.11 Skenario pertama pengujian fitur memeriksa keti-
daksesuaian dokumen rancangan . . . 201 5.12 Skenario kedua pengujian fitur memeriksa ketidak-
sesuaian dokumen rancangan . . . 203 5.13 Skenario pertama pengujian fitur mengekspor la-
poran hasil pemeriksaan ketidaksesuaian . . . 204 5.14 Skenario kedua pengujian fitur mengekspor laporan
hasil pemeriksaan ketidaksesuaian . . . 206 5.15 Hasil perhitungan kuesioner dalam bentuk pernyataan208 5.16 Hasil pengisian kuesioner untuk pertanyaan pertama 210 5.17 Hasil pengisian kuesioner untuk pertanyaan kedua . 211 5.18 Hasil pengisian kuesioner untuk pertanyaan ketiga . 212 5.19 Hasil pengisian kuesioner untuk pertanyaan keempat 214 5.20 Hasil pengisian kuesioner untuk pertanyaan kelima 214 5.21 Hasil pengujian fungsional . . . 219 5.22 Kategori nilai pernyataan usability . . . 220
xxi
xxii
2.1 Contoh diagram kasus penggunaan . . . . 11 2.2 Contoh diagram urutan . . . . 16 2.3 Contoh deskripsi kasus penggunaan pada aplikasi
StarUML 2 . . . . 27 2.4 Potongan hubungan semantik pada WordNet . . . . 39 2.5 Metrik knowledge-based similarity . . . . 40 3.1 Diagram kasus penggunaan kakas bantu . . . . 49 3.2 Kasus penggunaan “Memeriksa Ketidaksesuaian Do-
kumen Rancangan” . . . . 50 3.3 Diagram aktivitas kasus penggunaan “Memeriksa
Ketidaksesuaian Dokumen Rancangan” . . . . 52 3.4 Diagram aktivitas kasus penggunaan “Mengekspor
Laporan Hasil Pemeriksaan Ketidaksesuaian” . . . 53 3.5 Diagram urutan kasus penggunaan “Memeriksa Ke-
tidaksesuaian Dokumen Rancangan” . . . . 89 3.6 Diagram urutan proses mendeteksi ketidaksesuaian 90 3.7 Diagram urutan kasus penggunaan “Mengekspor La-
poran Hasil Pemeriksaan Ketidaksesuaian” . . . . 91 3.8 Diagram urutan proses mengekspor hasil deteksi ke
laporan . . . . 92 3.9 Arsitektur perangkat lunak . . . . 98 3.10 Struktur proyek dokumen rancangan pada aplikasi
StarUML 2 . . . . 99 3.11 Diagram kasus penggunaan “Online Shopping Sys-
tem” . . . 100 3.12 Alur dasar (basic flow) kasus penggunaan “Buy a
Product” . . . 100 3.13 Diagram urutan “Buy a Product” . . . 103 3.14 Contoh kelas (class) yang berinteraksi pada diagram
urutan “Buy a Product” . . . 111 3.15 Alur proses ekstraksi dokumen rancangan . . . 114
xxiii
3.17 Alur menghitung kemiripan kalimat alur kejadian dasar kasus penggunaan dan triplet . . . 119 3.18 Kelas diagram proses memasukkan dokumen ran-
cangan . . . 125 3.19 Kelas diagram proses mengekstraksi dokumen ran-
cangan . . . 128 3.20 Kelas diagram proses mendeteksi ketidaksesuaian . 135 3.21 Kelas diagram proses menghitung kemiripan kali-
mat alur kejadian dasar dan triplet . . . 143 3.22 Kelas diagram proses menampilkan hasil deteksi ke-
tidaksesuaian . . . 145 3.23 Kelas diagram proses memilih opsi ekspor hasil de-
teksi ketidaksesuaian . . . 150 3.24 Kelas diagram proses mengekspor hasil deteksi da-
lam bentuk laporan . . . 152 3.25 Diagram paket (package diagram) kakas bantu . . 158 4.1 Hasil implementasi antarmuka utama kakas bantu . 160 4.2 Hasil implementasi jendela “Masukan berkas doku-
men rancangan” . . . 161 4.3 Hasil implementasi antarmuka ekspor hasil peme-
riksaan ke dalam laporan . . . 162 4.4 Hasil implementasi jendela ”Simpan hasil” . . . . 162 5.1 Diagram urutan “Upload Event Proposal” . . . 192 5.2 Hasil deteksi ketidaksesuaian kasus penggunaan “Up-
load Event Proposal” . . . 192 5.3 Hasil deteksi ketidaksesuaian kasus penggunaan “Up-
load Event Proposal” (alur deskripsi terbalik) . . . 193 5.4 Hasil deteksi ketidaksesuaian kasus penggunaan “Up-
load Event Proposal” (salah satu alur deskripsi hilang)194 5.5 Hasil deteksi ketidaksesuaian pada antarmuka uta-
ma kakas bantu . . . 202
xxiv
5.8 Pesan kesalahan format berkas laporan hasil deteksi ketidaksesuaian . . . 207 A.1 Kasus penggunaan “Memeriksa Ketidaksesuaian Do-
kumen Rancangan” . . . 225 B.1 Diagram kasus penggunaan ARENA “Announce Tour-
nament” . . . 229 B.2 Diagram urutan ARENA “Announce Tournament” 230 B.3 Diagram kasus penggunaan ARENA “Chat with Play-
ers” . . . 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 Shutdo-
wn” . . . 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 Sys-
tem “Make Order Request” . . . 239
xxv
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 Pro-
gram “Disburse Payments” . . . 241 B.24 Diagram urutan Community Peace Progam “Dis-
burse Payments” . . . 241
xxvi
3.1 Elemen diagram kasus penggunaan “Online Shop- ping System” dalam XMI . . . 109 3.2 Elemen deskripsi kasus penggunaan “Buy a Prod-
uct” dalam XMI . . . 109 3.3 Elemen judul diagram urutan “Buy a Product” da-
lam XMI . . . 110 3.4 Elemen kelas sebuah diagram urutan dalam XMI . 111 3.5 Elemen pesan (message) sebuah diagram urutan da-
lam XMI . . . 112 4.1 Potongan kode fungsi mendeteksi ketidaksesuaian . 163 4.2 Potongan kode fungsi mengekstraksi dokumen ran-
cangan . . . 164 4.3 Potongan kode API dari SAX . . . 164 4.4 Potongan kode fungsi mengelompokkan nama ka-
sus penggunaan (use case) . . . 166 4.5 Potongan kode fungsi mendeteksi ketidaksesuaian . 167 4.6 Potongan kode pre-processing triplet . . . 169 4.7 Potongan kode pre-processing kalimat . . . 172 4.8 Potongan kode part-of-speech tagging dan lemma-
tization kalimat . . . 172 4.9 Potongan kode pengelompokan kata benda dan kata
kerja . . . 173 4.10 Potongan kode perhitungan kemiripan ruang seman-
tik kata benda dengan kata benda kalimat pertama . 174 4.11 Potongan kode mendapatkan vektor kata benda ka-
limat pertama . . . 176 4.12 Potongan kode menghitung nilai cosine similarity
kata benda . . . 177 4.13 Potongan kode menghitung nilai akhir kemiripan
semantik kalimat . . . 177 4.14 Potongan kode fungsi menghitung kemiripan seman-
tik kata dengan metrik Lin . . . 178
xxvii
suaian . . . 180 4.16 Potongan kode mengekspor hasil deteksi ketidakse-
suaian ke bentuk laporan . . . 182 4.17 Potongan kode mengolah kalimat alur kejadian da-
sar kasus penggunaan hasil deteksi ketidaksesuaian 183 4.18 Potongan kode mengolah triplet hasil deteksi keti-
daksesuaian . . . 184
xxviii
PENDAHULUAN
Bab ini membahas hal yang mendasari dilakukannya pengerja- an Tugas Akhir ini dan identifikasi dari permasalahan yang akan diteliti.
1.1 Latar Belakang
Daur hidup pengembangan perangkat lunak (software develop- ment life cycle) membagi aktivitas pengembangan ke dalam tahap merencanakan, menganalisis, merancang, mengimplementasikan, dan merawat perangkat lunak. Tahap pertama pengembangan pe- rangkat lunak diawali dengan merencanakan proyek perangkat lu- nak. Kemudian, tahap berikutnya adalah tahap analisis. Seorang analis sistem memiliki peranan penting pada tahap ini untuk menga- nalisis dan mengembangkan kebutuhan pengguna ke dalam sebuah dokumen spesifikasi kebutuhan. Dokumen spesifikasi kebutuhan yang dihasilkan akan menjadi panduan pengembang untuk mema- hami 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 terse- but dengan merancang diagram UML. Salah satu diagram yang di- rancang adalah diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram). Diagram kasus penggunaan menggambarkan aktor, kasus penggunaan (use case), dan interaksi- nya 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 men- jadi panduan untuk menyusun diagram urutan. Analis sistem me- nurunkan alur kejadian pada deskripsi kasus penggunaan menjadi kelas-kelas (class). Kelas-kelas ini nantinya berinteraksi di dalam
1
diagram urutan melalui serangkaian pesan (message). Analis sis- tem perlu memeriksa dan memperbaiki rancangan diagram apabila ditemukan ketidaksesuaian selama iterasi pengembangan. Ketidak- sesuaian 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 bound- ary pada diagram urutan. Tujuan dari pemeriksaan ketidaksesuai- an adalah melihat konsistensi logika interaksi antara diagram ka- sus penggunaan dan diagram urutan karena pada dasarnya diagram urutan merupakan realisasi dari skenario diagram kasus pengguna- an. Rancangan diagram yang sesuai berpengaruh kepada ketepatan (correctness) implementasi perangkat lunak. Namun, pemeriksa- an 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 ala-
mi (natural language processing). Pemrosesan bahasa alami yang
digunakan adalah perhitungan kemiripan semantik kalimat. Pende-
teksian ketidaksesuaian dilakukan dengan melakukan ekstraksi des-
kripsi kasus penggunaan dan diagram urutan dari dokumen rancang-
an. Untuk deskripsi kasus penggunaan, mengambil kalimat alur ke-
jadian kasus penggunaan, sedangkan diagram urutan, mengambil
triplet. Triplet terdiri dari nama aktor, message, boundary class atau
nama control class, message, boundary class. Kemudian, menghi-
tung kemiripan semantik antara kalimat alur kejadian kasus peng-
gunaan dengan triplet. Perhitungan kemiripan semantik kalimat di-
gunakan dalam pendeteksian karena adanya perbedaan bahasa pa-
da kalimat alur kejadian kasus penggunaan (menggunakan bahasa pengguna) dan triplet (menggunakan bahasa pengembang). Perbe- daan ini terjadi saat analis sistem menurunkan kalimat alur kejadian kasus penggunaan ke dalam kelas-kelas selama tahap analisis. Con- toh, kata “window” pada kalimat alur kejadian kasus penggunaan menjadi “GUI” pada triplet. Nilai kemiripan kalimat yang mele- wati ambang batas (threshold) yang telah ditentukan menjadi dasar penilaian ketidaksesuaian. Hasil pendeteksian dinyatakan dalam se- buah daftar yang berisi nama kasus penggunaan, kalimat alur keja- dian kasus penggunaan, dan triplet dengan penanda “Sesuai” atau
“Tidak sesuai”. Sehingga, pembuatan kakas bantu ini diharapkan tidak hanya membantu analis sistem menghasilkan rancangan dia- gram yang sesuai akan tetapi mempercepat waktu pengembangan perangkat lunak.
1.2 Rumusan Masalah
Rumusan masalah yang diangkat dalam Tugas Akhir ini dipa- parkan sebagai berikut:
1. Bagaimana mengekstraksi deskripsi kasus penggunaan dan dia- gram urutan dari dokumen rancangan?
2. Bagaimana menghitung kemiripan antara kalimat alur kejadian kasus penggunaan pada deksripsi kasus penggunaan dengan trip- let pada diagram urutan?
3. Bagaimana membangun kakas bantu yang dapat mendeteksi ke- tidaksesuaian antara diagram urutan dan diagram kasus penggu- naan?
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
deskripsinya dan diagram urutan dari satu sistem, misal sistem ATM.
2. Deskripsi kasus penggunaan berisi kalimat alur kejadian dasar (basic flow) dari kasus penggunaan.
3. Dokumen rancangan dibuat dengan menggunakan aplikasi pe- modelan StarUML 2 [2].
4. Dokumen rancangan dalam format “.xmi”. Berkas tersebut di- hasilkan melalui penggunaan XMI extension StarUML 2 [3].
5. Bahasa yang digunakan pada dokumen rancangan adalah bahasa Inggris.
6. 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 urut- an (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 peng- gunaan.
2. Mempercepat waktu pengembangan perangkat lunak dari sebuah proyek perangkat lunak.
1.6 Metodologi
Tahapan-tahapan untuk mengerjakan Tugas Akhir ini dijabar-
kan sebagai berikut:
1. Penyusunan proposal Tugas Akhir
Proposal Tugas Akhir berisi gagasan dari Tugas Akhir yang akan dikerjakan. Proposal Tugas Akhir berisi pendahuluan yang ter- diri dari latar belakang diajukannya usulan Tugas Akhir, rumus- an masalah yang diangkat, batasan masalah, tujuan, dan manfaat dari pembuatan tugas akhir. Selain itu, tinjauan pustaka yang di- gunakan juga dijabarkan sebagai referensi pendukung pengerja- an Tugas Akhir. Subbab metodologi berisi penjelasan mengenai tahapan penyusunan Tugas Akhir mulai dari penyusunan propo- sal hingga penyusunan buku Tugas Akhir. Terdapat pula sub- bab jadwal kegiatan yang menjelaskan jadwal pengerjaan Tugas Akhir.
2. Studi literatur
Studi literatur yang dipelajari untuk mendukung pengerjaan Tu- gas Akhir, antara lain diagram kasus penggunaan (use case di- agram), deskripsi kasus penggunaan (use case description), di- agram urutan (sequence diagram), konsep ketidaksesuaian dia- gram urutan dan diagram kasus penggunaan, XML Metadata In- terchange (XMI), StarUML, dan pemrosesan bahasa alami (na- tural language processing). Selain itu, metode perhitungan ke- miripan 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 pe- ngembangan perangkat lunak berbasis objek. Analisis dan pe- rancangan sistem diawali dengan analisis dan pendefinisian ke- butuhan sistem terhadap masalah yang sedang dihadapi. Selain itu, analisis aktor dan kandidat-kandidat kelas (class) yang ber- interaksi di dalam sistem. Tahap perancangan dibagi menjadi beberapa tahap. Tahap tersebut antara lain:
(a) Perancangan diagram UML,
(b) Perancangan antarmuka perangkat lunak, dan
(c) Perancangan proses perancangan lunak.
4. Implementasi sistem
Tahap ini dilakukan implementasi perangkat lunak. Implemen- tasi perangkat lunak didasarkan pada perancangan sistem yang telah dilakukan sebelumnya. Perangkat lunak diimplementasi- kan dengan bahasa pemrograman Java. Adapun tahap imple- mentasi perangkat lunak. Tahap tersebut antara lain:
(a) Implementasi antarmuka perangkat lunak,
(b) Implementasi ekstraksi deskripsi kasus penggunaan dan di- agram urutan dari sebuah dokumen rancangan,
(c) Implementasi pemecahan kalimat (sentence breaking), pe- nentuan kelas kata (part-of-speech tagging), dan pemben- tukan kata dasar (lemmatization) pada suatu kalimat, (d) Implementasi perhitungan kemiripan semantik antar kali-
mat.
(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 pendekat- an perhitungan kemiripan semantik kalimat yang telah di- pilih. Hasil pengujian ini digunakan sebagai dasar menen- tukan ambang batas (threshold) terbaik untuk mendeteksi ketidaksesuaian antara diagram kasus penggunaan dan dia- gram urutan.
(b) Pengujian data uji (testing data) dengan menerapkan am- bang batas terbaik yang telah didapatkan sebelumnya. Hasil pengujian ini digunakan untuk membandingkan hasil peme- riksaan ketidaksesuaian oleh perangkat lunak dengan ahli rekayasa perangkat lunak.
(c) Pengujian fungsional perangkat lunak dengan mengguna-
kan black-box testing. Pengujian dengan metode ini bertu-
juan untuk mengetahui apakah perangkat lunak yang diba- ngun sudah sesuai dengan hasil yang diharapkan.
(d) Pengujian non-fungsional perangkat lunak untuk aspek usa- bility. 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 doku- men rancangan berasal dari buku dengan topik rekayasa perang- kat 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 da- ri implementasi perangkat lunak yang telah dibuat. Sistematika penulisan buku Tugas Akhir secara garis besar, terdiri dari pen- dahuluan, tinjauan pustaka, analisis dan perancangan sistem, im- plementasi 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 pengerja- an Tugas Akhir. Selain itu, rumusan masalah, batasan masalah, metodologi, dan sistematika penulisan Tugas Akhir juga meru- pakan bagian dari bab ini.
2. Bab II Tinjauan Pustaka
Bab ini berisi penjelasan dasar teori dan penunjang yang diguna-
kan untuk mendukung pengerjaan Tugas Akhir. Dasar teori yang
digunakan, antara lain diagram kasus penggunaan (use case di-
agram), deskripsi kasus penggunaan (use case description), di- agram urutan (sequence diagram), konsep ketidaksesuaian dia- gram urutan dan diagram kasus penggunaan, XML Metadata In- terchange (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 di- buat. Analisis perangkat lunak mendefinisikan kebutuhan sis- tem 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 anta- ranya, 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 perang- kat lunak yang telah dilakukan sebelumnya. Penjelasan berupa deskripsi dengan potongan kode sumber dari proses yang ter- jadi di dalam perangkat lunak. Proses tersebut antara lain, pro- ses mengekstraksi deskripsi kasus penggunaan dan diagram urut- an dari dokumen rancangan, proses mendeteksi ketidaksesuaian, proses menghitung kemiripan kalimat antara kalimat alur keja- dian kasus penggunaan dengan triplet, proses menghitung kemi- ripan kata, dan proses mengekspor hasil deteksi ketidaksesuaian ke bentuk laporan. Selain itu, implementasi dari antarmuka pe- rangkat lunak juga dibahas dalam bab ini.
5. Bab V Pengujian dan Evaluasi
Bab ini membahas pengujian hasil deteksi ketidaksesuaian de-
ngan membandingkan hasil dari perangkat lunak dan dari ahli
melalui dokumen rancangan yang diujikan. Penjelasan pengu-
jian data pelatihan juga dijelaskan di dalam bab ini. Evaluasi
pengujian hasil deteksi ketidaksesuaian ditentukan melalui se- berapa besar kesepakatan antara perangkat lunak dengan ahli.
Kesepakatan tersebut dapat ditentukan melalui nilai kappa sta- tistic [35]. Selain itu, terdapat pengujian fungsional perangkat lunak melalui black-box testing dan non-fungsional perangkat lunak pada aspek usability. Hasil pengujian fungsional diten- tukan 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 dilaku-
kan dan saran untuk pengembangan perangkat lunak ke depan-
nya.
Halaman ini sengaja dikosongkan
TINJAUAN PUSTAKA
Bab ini berisi dasar teori, publikasi ilmiah, dan kakas bantu atau pustaka perangkat lunak yang digunakan untuk menunjang pembu- atan 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 stan- dar UML 2. Salah satunya adalah aplikasi StarUML [2]. Diagram kasus penggunaan adalah gambaran grafis dari aktor, kasus peng- gunaan (use case), dan interaksinya yang menggambarkan sistem yang akan dibangun.
Gambar 2.1 Contoh diagram kasus penggunaan (use case diagram)
11Contoh diagram diambil darihttps://www.andrew.cmu.edu/course/
90-754/umlucdfaq.html(diakses terakhir 26 Juni 2016).
11
Tujuan dari pembuatan diagram kasus penggunaan adalah seba- gai alat mendokumentasikan kebutuhan dasar aktor dan bagaimana kebutuhan tersebut akan dipenuhi. Selain itu, diagram ini juga ber- fungsi sebagai alat mengomunikasikan fungsionalitas sistem kepa- da stakeholder (pihak yang memiliki kepentingan terhadap sistem yang akan dibangun) karena kasus penggunaan menggunakan ba- hasa 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 ka- sus 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 Notasi Keterangan
Aktor (actor)
Menggambarkan suatu peran yang dilakukan oleh objek yang berada di luar sistem yang berinteraksi langsung dengan sistem.
“Photographer”
menunjukkan nama dari aktor.
Kasus Penggunaan
(use case)
Deskripsi sebuah perilaku sistem sebagai respon dari suatu aksi dari luar sistem (interaksi antara aktor dan sistem). “Take Picture”
menunjukkan nama kasus
penggunaan.
Tabel 2.1 Komponen diagram kasus penggunaan (use case diagram) (lanjutan)
Nama Notasi Keterangan
Asosiasi (as- sociation)
Hubungan atau relasi dari aktor ke kasus penggunaan.
Include
Hubungan atau relasi yang mengindikasikan suatu kasus penggunaan utama (base use case) merujuk dan melibatkan perilaku sub-kasus penggunaan (sub-use case) lain.
Extend
Hubungan atau relasi yang mengindikasikan suatu kasus penggunaan utama diperluas dengan perilaku sub-kasus penggunaan lain.
Generalisasi (generaliza-
tion)
Menggambarkan
generalisasi dari sejumlah kasus penggunaan atau aktor yang lain.
Batas sistem (system boundary)
Menggambarkan batas antara aktor dan sistem.
Terdapat kasus penggunaan apa saja yang ada di dalam sistem tersebut. “Camera”
menunjukkan nama dari
sistem.
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 deskrip- si kasus penggunaan. Interaksi aktor dan kasus penggunaan dides- kripsikan melalui sebuah skenario dalam deskripsi kasus pengguna- an. Setiap deskripsi kasus penggunaan harus mengandung informa- si 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 pascakon- disi 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 pa- ragraf.
2. Flow of Events 2.1 Basic Flow
Mendefinisikan kapan dan bagaimana kasus penggunaan mulai dan berakhir. Selain itu, aktor mana yang mengawali kasus peng- gunaan. Deskripsi ini berupa skenario dalam bentuk dialog antara aktor dan sistem (aktor melakukan apa dan respon apa yang diberi- kan oleh sistem). Dialog tersebut ditulis dalam sebuah urutan.
2.2 Alternative Flow
2.2.1 <First Alternative Flow>
Mendefinisikan alur alternatif karena sebab tertentu pada skena-
rio 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.
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 berben- tuk dialog aktor dan sistem yang ditulis dalam sebuah urutan.
3. Special Requirements
3.1 < First Special Requirement >
Mendefinisikan pemenuhan atau kondisi khusus agar kasus peng- gunaan 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 peng- gunaan 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
[1]. Bagian flow of events pada deskripsi kasus penggunaan men- jadi 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 menggambar- kan perilaku objek yang ada pada kasus penggunaan (use case) de- ngan mendeskripsikan pesan (message) yang dimiliki kelas (class).
Diagram ini juga merupakan salah satu jenis diagram UML, di sam- ping diagram kasus penggunaan (use case diagram) yang telah di- bahas sebelumnya.
Gambar 2.2 Contoh diagram urutan (sequence diagram)
22Contoh diagram diambil dari http://www1.unipa.it/manfredi.
bruccoleri/bpm/Week_6_files/Es%204%20Solution.pdf (diakses terakhir 26 Juni 2016).
Realisasi kasus penggunaan dalam bentuk skenario pada deskripsi kasus penggunaan (use case description) secara detail digambarkan pada diagram ini. Diagram urutan mengekspresikan skenario ber- dasarkan urutan waktu, apa yang terjadi pertama kali, berikutnya, dan seterusnya. Hal tersebut digunakan untuk mendefinisikan urut- an pesan (message ordering).
Tujuan dari pembuatan diagram urutan adalah sebagai alat pe- lacak kesesuaian logika interaksi antara objek-objek di dalam sis- tem sesuai urutan waktu interaksi tersebut terjadi. Kesesuaian inte- raksi antara skenario pada deskripsi kasus penggunaan bisa dilihat dengan menggunakan diagram ini. Pada dasarnya, diagram urutan menunjukkan perilaku kasus penggunaan yang hendak diimplemen- tasikan ke dalam perangkat lunak. Gambaran umum diagram urutan digambarkan pada Gambar 2.2. Dari gambar tersebut, diagram ter- diri 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 de- tail pada Tabel 2.2.
Tabel 2.2 Komponen diagram urutan (sequence diagram)
Nama Notasi Keterangan
Aktor (actor)
Menggambarkan suatu peran yang dilakukan oleh objek di luar sistem (entitas eksternal) yang berinteraksi langsung dengan sistem.
“Passenger” merupakan
nama dari aktor.
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
Menggambarkan durasi pengerjaan sebuah pesan (message).
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.
Tabel 2.2 Komponen diagram urutan (sequence diagram) (lanjutan)
Nama Notasi Keterangan
Reply Message
Menggambarkan umpan balik (feedback) sebuah operasi pada pesan.
“amountDue” merupakan nama hasil kembalian sebuah operasi pada pesan.
Asynchrono- us Message
Menggambarkan jenis pesan di mana pesan ini mengaktifkan sebuah operasi yang berjalan bersamaan dengan sebuah operasi lain dari suatu pesan.
Create Message
Menggambarkan jenis pesan untuk membuat sebuah objek baru yang dikirim oleh objek yang lain.
Delete Message
Menggambarkan jenis pesan untuk
menghancurkan sebuah
objek yang dikirim oleh
objek lain.
Tabel 2.2 Komponen diagram urutan (sequence diagram) (lanjutan)
Nama Notasi Keterangan
Interaction
Menggambarkan sebuah dasar dari diagram urutan untuk meletakkan
komponennya secara konsisten. Terdapat nama kasus penggunaan pada pojok kiri atas.
2.4 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 pengguna- an [5]. Skenario berupa interaksi aktor dan sistem pada dalam ben- tuk 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 keti- daksesuaian.
Skenario kasus penggunaan dibuat saat tahap elisitasi kebu-
tuhan, sedangkan diagram urutan dibuat saat tahap analisis. Tahap
analisis fokus untuk menghasilkan model sistem yang benar, leng-
kap, konsisten, dan bisa diverifikasi [6]. Model yang dihasilkan
ada tiga jenis, yaitu functional model, object model, dan dynamic
model. Functional model direpresentasikan oleh kasus pengguna-
an dan skenarionya, object model direpresentasikan oleh diagram
kelas (class diagram), dan dynamic model direpresentasikan oleh
diagram urutan. Saat menganalisis object model, analis sistem me- nentukan tiga jenis kandidat objek (boundary, control, dan entity) dari skenario kasus penggunaan. Pendekatan yang digunakan untuk menentukan kandidat kelas adalah menelusuri kata benda pada ske- nario kasus penggunaan. Contoh, kata catalog pada alur skenario customer browses through catalog menjadi kelas
BrowseInter- facedengan jenis objek boundary. Kata kerja pada alur skenario memjadi kandidat pesan atau operasi kelas. Mengambil contoh se- belumnya, kata kerja browses menjadi operasi
browseItem.
Tahap analisis object model dilanjutkan dengan analisis dyna- mic model. Tahap ini dilakukan pemetaan kasus penggunaan men- jadi diagram urutan. Diagram urutan bergantung pada kasus peng- gunaan dengan objek-objeknya. Hasil dari analisis object model berupa objek-objek dengan operasinya saling berinteraksi pada dia- gram urutan. Bagian yang paling penting pada diagram urutan ada- lah urutan operasi yang dikirimkan dari objek satu ke objek lainnya.
Hal ini disebabkan diagram urutan merealisasikan perilaku objek- objek yang ada pada skenario kasus penggunaan.
2.5
XML Metadata Interchange (XMI)XML Metadata Interchange (XMI) [7] adalah sebuah stan- dar pertukaran informasi metadata melalui Extensible Markup Lan- guage (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 informa- si metadata ke sebuah teks dalam format XML, XMI mendefinisi- kan serangkaian aturan meta-model berdasarkan MOF meta-meta- model. Salah satu contoh meta-model adalah UML (unified model- ing language).
Sebuah UML didefinisikan sebagai sebuah model yang terdiri
dari informasi metadata yang saling berkaitan karena mendeskrip-
sikan informasi yang saling berhubungan, mendefinisikan sebuah rangkaian aturan yang mendefinisikan struktur dan konsistensi, dan memiliki makna dalam sebuah kerangka semantik umum [9]. Ke- lebihan dari XMI adalah portability, memungkinkan sebuah model bisa digunakan di berbagai jenis kakas rekayasa perangkat lunak.
Hal tersebut bisa dilakukan karena XMI mengandung informasi me- tadata yang bisa direpresentasikan ke dalam sebuah diagram UML atau sebaliknya dari diagram UML ke XMI (reverse engineering).
Ada berbagai jenis aplikasi pemodelan UML yang mendu- kung konversi dari diagram UML ke dalam XMI atau sebaliknya dari XMI ke diagram UML. StarUML merupakan salah satu aplika- si yang menyediakan fitur tersebut. Fitur ini bisa dijalankan dengan menambahkan XMI extension [3] pada aplikasi StarUML 2 [2]. De- ngan menggunakan bantuan extension tersebut, elemen yang ada pada XMI bisa menunjukkan apa dan bagaimana komponen yang ada pada rancangan diagram UML disusun. Setiap elemen terdi- ri 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 Keterangan
<?xml ... ?>
version
Mendefinisikan versi XML pada setiap deklarasi dokumen XML.
encoding
Mendefinisikan karakter unicode yang digunakan.
Biasanya, UTF-8 yang paling sering digunakan.
Tabel 2.3 Elemen penting XMI pada diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram)
(lanjutan)
Elemen Atribut Keterangan
xmi:XMI
xmi:ver-
sion Mendefinisikan versi XMI.
xmlns:uml
Mendefinisikasi standar spesifikasi UML pada setiap deklarasi XMI.
xmlns:xmi
Mendefinisikan standar spesifikasi XMI pada setiap deklarasi XMI.
xmi:Documentation
exporter
Mendefinisikan nama ektensi (extension) yang mengekspor berkas UML ke dalam XMI.
exporter- Version
Mendefinisikan versi kakas yang melakukan konversi diagram UML ke XMI.
uml:Model
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.
packagedElement
xmi:id
Menunjukkan nilai unik setiap komponen rancangan.
Nilai berupa UUID.
Tabel 2.3 Elemen penting XMI pada diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram)
(lanjutan)
Elemen Atribut Keterangan
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.
ownedMember
xmi:id
Menunjukkan nilai unik setiap komponen rancangan.
Nilai berupa UUID.
xmi:type
Mendefinisikan deklarasi anggota atau komponen lain yang terlibat. Bisa digunakan untuk hubungan asosiasi suatu kasus penggunaan atau menemukan judul frame diagram urutan.
ownedEnd
xmi:id
Menunjukkan nilai unik setiap komponen rancangan.
Nilai berupa UUID.
type
Menunjukkan referensi UUID komponen yang terlibat.
Tabel 2.3 Elemen penting XMI pada diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram)
(lanjutan)
Elemen Atribut Keterangan
xmi:type
Mendefinisikan anggota atau komponen mana saja yang terlibat dalam hubungan asosiasi suatu kasus penggunaan.
memberEnd xmi:idref Mendefinisikan referensi UUID dariownedEnd.
documentation value
Mendefinisikan dokumentasi diagram UML. Misal, deskripsi kasus penggunaan.
Nilai terdapat pada atribut value.
lifeline
xmi:id
Menunjukkan nilai unik setiap komponen rancangan.
Nilai berupa UUID.
name Menunjukkan nama dari lifeline.
xmi:type
Menunjukkan komponen lifeline. Nilai atribut ini adalahuml:Lifeline.
represents
Mendefinisikan komponen lifeline. Nilainame menunjukkan nama objek danrepresentsreferensi UUID dari kelas (class) yang bersangkutan.
Tabel 2.3 Elemen penting XMI pada diagram kasus penggunaan (use case diagram) dan diagram urutan (sequence diagram)
(lanjutan)
Elemen Atribut Keterangan
message
xmi:id
Menunjukkan nilai unik setiap komponen rancangan.
Nilai berupa UUID.
name Menunjukkan nama message.
xmi:type
Menunjukkan komponen message. Nilai atribut ini adalahuml:Message.
message- Sort
Menunjukkan jenis message.
Jenis message bisa berupa synchronous, asynchronous, atau reply message.
receive- Event
Menunjukkan referensi UUID dari lifeline yang menerima message tersebut.
sendEvent
Menunjukkan referensi UUID dari lifeline yang mengirim message tersebut.
fragment
xmi:id
Menunjukkan nilai unik setiap komponen rancangan.
Nilai berupa UUID.
covered Nilaicoveredmenunjukkan referensi UUID dari lifeline.
xmi:type
Mendefinisikan komponen fragment yang bernilai uml:OccurrenceSpeci- fication.
2.6
StarUMLStarUML [2] adalah sebuah aplikasi pemodelan UML (unified mod- eling language) yang dikembangkan oleh MKLab. StarUML dikembang- kan 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 sesu- ai dengan standar UML 2, pengecekan model UML sesuai aturan, dan pe- nambahan fungsional melalui extension. Aplikasi ini terdiri dari dua ver- si, 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 terse- but 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 men- dukung ekspor dan impor XMI dari diagram UML akan tetapi dokumenta- si komponen-komponen yang ada pada diagram UML. Dokumentasi beru- pa plain text yang berisi penjelasan suatu komponen diagram UML. Con- toh dokumentasi diagram kasus penggunaan dari kasus penggunaan (use
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 penggu- naan “Take Picture” yang sedang dipilih (tengah) dan dokumentasi dari kasus penggunaan tersebut (pojok kanan bawah). Dokumentasi menun- jukkan teks yang berisi deskripsi dari kasus penggunaan “Take Picture”, seperti deskripsi singkat (brief description) dan alur kejadian dasar (ba- sic 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 un- tuk digunakan pada jenis aplikasi pemodelan UML yang berbeda. Namun, hasil XMI dari StarUML 2 tidak bisa digunakan di StarUML v1 dan seba- liknya karena perbedaan versi XMI.
2.7 Pemrosesan Bahasa Alami (Natural Language
Processing)Pemrosesan bahasa alami atau yang dikenal dengan NLP adalah ca- bang ilmu komputer yang mengkaji interaksi antara komputer dengan ba- hasa (alami) manusia. Adapun ranah penelitian yang sering dijadikan ob- jek penelitian NLP. Ranah penelitian tersebut, antara lain automatic sum- marization, machine translation, morphological segmentation, name en- tity recognition (NER), part-of-speech tagging, parsing, question answer- ing, sentence breaking, sentiment analysis, dan word sense disambigua- tion. 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 (?). Na- mun, tidak semua kalimat bisa ditandai melalui tanda baca tersebut.
Contoh, teks “Since 2011, Gov. Bill Haslam and the General Assem- bly have partnered to increase education funding by more than $730 million, including more than $340 million for teacher salaries. Edu- cation 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-
