BAB III METODOLOGI
3.1
Sistem Yang Sedang Be rjalan
Saat ini, perpustakaan BI NUS Univ ersity m enyimpan banyak file dok um en yan g ber bentuk digital. Dok umen digital yang ter dapat di perp ustakaan sangat beragam , diantaranya ada e-thesis, e-journal, case stud y, dll. Pen gaturan penyimpanan dok umen ini sudah baik dengan dikelompokkan masing-masin g.
G am bar 3.1 Tampilan Saat Penyimpanan Dokumen 125
126
Dari gam bar di atas, terlihat sudah dilakuk an pen gelompokan saat penyim panan awal (lih at bagian subject). Dilihat dari aspek pencarian dokumen tersebut, yang dilak ukan pada sistem ini adalah, u ser diberikan r uan g untuk m elak ukan input keyword apa yan g h endak dicari, dan berdasark an pada value apa pen carian itu dilak ukan.
G ambar 3.2 Tam pilan Saat Melakukan Pencarian
Dari gam bar di atas jelas dipapark an bahwa variabel yan g bisa digunakan sebagai keywo rd pencarian adalah Title, Author, Publish er, Department, Advisor, dan Subject. Yan g u ser lak uk an adalah men g-input-kan keywo rd tertentu setelah m em ilih variabel yan g hendak diban din gkan.
Fitur yan g diberik an oleh LKC ( Libra ry and Kno wledg e Cen ter) BI NUS University sekarang menyediak an suatu op erator Boolean, yang ter diri dari And, Or, dan No t. Pencar ian dengan lebih dari satu var iabel pemban ding biasanya m em bantu m enghasilkan suat u pencarian yang ber sifat lebih menyeluruh dari
127
selur uh dokum en yan g dicari. Secara sepintas, hasil pencarian dinilai sudah memberikan h asil yan g match sesuai u ser request, nam un ternyata sebenarnya belum bisa dikatakan dem ikian. Apabila ditinjau lebih jauh, ketika kita melak ukan kom parasi kep ada mesin pencari Google, banyak sekali keter batasan yan g m asih ada pada m esin pen cari y ang ada di perp ustakaan in i. Sebagai salah satu contohnya saja, di mesin pencari yan g sekaran g ini ada, hanya terbatas p ada 2 v ariabel sebagai keywo rd, sedan gkan Google bisa melak ukan query terhadap string yan g cukup panjang, dim ana di dalamnya mem ungkinkan ada Op erator Boo lean. Sistem ini merup akan p erbaikan-per baikan dari sistem yang ada sebelum nya. Perbaikan yan g terjadi bersifat adding; tam bal sulam. Hal ini bukan merup akan sesuatu yang menjawab unt uk per baikan yan g maksim al. Walaup un apabila dilakukan modifikasi menyelur uh terhadap yan g sudah ada akan menghasilkan sistem yang lebih ef isien dan ef ektif, hal ini tidak dilak ukan. Pihak developer menjelaskan bah wa apabila dilak ukan mo difik asi terhadap sistem secara keselur uhan, akan memerlukan waktu yang cuk up lam a, seh ingga m ereka tidak dilakukan m odifik asi terhadap sistem .
Idealnya adalah dilak ukan perom bak an pada sistem yang ada gun a m en dapatkan sebuah sistem yang lebih baik. Karenany a, dinilai perlu dilakuk an pen gem ban gan ulan g dar i sistem secar a menyeluruh. Sehingga, akan menghasilkan satu pengolahan da tabase yan g lebih baik sehingga m em ori yang digun akan lebih kecil serta manajemen file-nya lebih terstr uktur.
128
Lebih lanjut lagi, pejabat perp ustakaan m engem ukakan perlu untuk membangun sebuah sistem pencarian yan g m e-refer tidak hanya k e judul, kategori, atau keywo rd lainnya. Beliau menjelask an bahwa LKC BI NUS Univer sity memerlukan sebuah advanced search yan g bisa mencar i hin gga keywo rd yang ada pada konten dari dok umen. 1. Analisis data Pengolahan data tentunya m embutuhkan tempat penyim panan, yaitu database. Database y an g digunakan di LKC saat ini adalah menggun akan RDBMS (Rela tional Database Management System). Softwa re yan g digun akan untuk p enyimpanan ke dalam database in i adalah M ySQL Server. Strukt ur dari tabel dapat dilihat pada gam bar ERD sistem .
Jika k ita melihat pada ERD, hampir setiap tabel mem iliki tabel tam bahan yaitu tabel subject. Kita am bil sebagai contoh yaitu table ms_infoPackage, m s_ERiset, dan ms_Epaper. Dari tabel-tabel tersebut, terdapat tam bahan tabel yan g diakhiri den gan kata subject. Pada tabel tam bah an itu, setiap tabel _subject m em iliki detail yang ham pir sama. Hal ini m erup akan sebuah ketidakef isienan jumlah tabel, y ang ak an terkait pada m emory space penyim panan.
Penggunaan pemodelan ERD ini tidak men duk un g unt uk proses pengindek san dokum en. Tabel yan g ada cen der ung indepen den, dimana tingkat ketergantun gan sat u sama lain tidak terlalu tinggi. Kategori yan g ada, satu den gan yan g lainnya tidak terh ubung.
129
G am bar 3.3 ERD dari Current System
130
2. Analisis Pro ses Proses pada saat melakukan pen ginp utan dokumen yan g baru adalah: • Administra tor melak ukan penginp utan dok um en bar u beserta dengan semua detail atributnya
G ambar 3.4 Tam pilan Input Data Collection kategori Thesis • Tempat penyim panan dok um en
dilihat dari kategorinya. Tabel
penyim panannya ter gantung kategor i yang dipilih.
131
• Tem pat penyim panan terdiri dari banyak tabel yan g sudah dipisahkan satu den gan y ang lain sesuai kategori datanya. Lebih jelasnya, dapat dilihat pada ERD, Gam bar 3.4. • Tidak ada validasi terhadap data yang sam a atau ser upa
G am bar 3.5 DFD Penyim panan Dokumen pada Current System
Sedangk an unt uk proses query atau pengambilan dokumen dar i database adalah : •
User m elak ukan query den gan m elak ukan input keyword
•
Hasil qu ery kemudian diproses m enuju ke database
•
Kategori yang ada m enentukan tabel mana yan g dituju untuk mengam bil dok um en yan g dicari
•
Sem ua dok um en yan g m engan dun g keywo rd inp utan dari user ditampilkan pada hasil pencarian
132
Gambar 3.6 DFD Proses Q uery Dokumen pada Current System
Dari gam bar DFD di atas, kita bisa melih at aliran setiap data m ulai dari penyimpanan, juga pada saat proses retrieva l, sehin gga bisa dianalisis kekur an gan yan g ada di sistem ini. Kekur an gan yan g ditem ukan diantaranya adalah: •
Proses validasi data tidak ada pada saat penyim panan dok umen yang bar u, sehin gga bisa terjadi tumpang tindih antara data yan g sama
•
Tidak ada pembobotan, sehin gga hasil dari retrieve data hanya diurutkan berdasark an nomor bibli. Proses pencar ian terhadap dokumen yan g palin g relevan m enjadi sulit, sebab tidak diur utkan berdasarkan yan g paling cocok.
133
3.2
Masalah Pencarian yang Dihada pi Saat Ini
Uraian yan g diber ikan p ada bagian sistem yan g sedan g ber jalan di atas sudah cuk up mem ber ikan sat u gambar an permasalahan yang LKC hadapi saat ini. Yan g kem udian memun culkan keingin an suatu pen gak sesan dok umen digital yan g mampu m emberikan hasil yan g lebih menyelur uh, sehingga apa yan g u ser inginkan lebih len gkap. Pencarian m enjadi lebih ak urat apabila dicari h in gga ke dalam konten (isi) dok um en ter sebut, tidak h anya judul, autho r dkk. Diharapkan tingkat accessibility dok umen setelah per baik an yan g dilakukan menjadi lebih tinggi.
3.3
Rumusa n Pemecahan Masalah
Akan dirancan g sebuah sistem yang cuk up besar di m ana didalam nya ter dapat 4 sub sistem yang m elakuk an pen gatur an, tidak hanya dari sisi pen in gkatan yan g menyeluruh dari h asil pencar ian, nam un ak an m e-manage sem ua dok um en yan g disimpan h ingga pro ses retrieval-ny a. Namun, y ang menjadi perhatian utama adalah untuk m em berikan hasil p encar ian y ang memiliki sifat lebih menyeluruh sesuai den gan kein ginan u ser. Metodologi yang digunak an, adalah Unified Process, dimana pada awalny a, akan dianalisis p ermasalahan yan g ada, kem udian diterjemahkan m enjadi bentuk diagram use case. Dari u se case ini akan terlihat setiap aktivitas yang ada di dalam sistem secara m endetail.
Lan gkah selan jutnya, setelah use case didefin isikan secara detail dan benar, dilakukan analisis objek-objek yan g saling berinterak si di dalam nya. Dan dari
134
situlah akan diran can g sebuah class diagram yan g akan m erepresentasik an o bjekobjek yan g berp eran dalam sistem.
Class-cla ss yan g terbentuk akan m embentuk suat u integrasi sistem secara keseluruhan, dar i mulai dok umen di-in sert untuk dilak ukan indexing yan g kemudian disimpan ke dalam database, dan juga pro ses retrieval dar i dok um en saat user melakukan submit query ke sistem .
3.4
Analisi s Sistem Yang Dirancang
Sistem yang dibangun m er upak an sebuah sistem besar yang terintegrasi m enjadi satu, menjadi sebuah Docum ent Sea rch Eng ine.
Gambar 3.7 Diagram Proses dari Document Search Engine
135
Secara keselur uhan proses pada sistem pencarian dokum en dibagi menjadi 4 bagian yaitu indexer system, inverted files system, application server system dan web server system . Dimana pada m asin g-m asing bagian memiliki proses yan g ber beda-beda.
1. Indexer System Sistem ini mengatur hal-hal yan g berkaitan langsun g den gan administrator dalam hal pen gat uran terhadap dok umen. Di dalam nya ada proses pemilihan dok um en yan g akan diin deks, kemudian pen gin dek san dari dokum en tersebut untuk dim asukkan ke dalam database.
136
G am bar 3.8 Diagram Proses dari Indexer System Proses y ang terjadi pada indexing adalah mengh ilan gkan tag-tag HTML pada dok um en, mengh ilan gkan stop word s, mengh ilan gkan tanda baca, tokenisasi dokumen ke dalam bentuk token-token, mengubah m asin gm asin g token ke dalam akar k ata, dan menghitun g fr ekuensi kemunculan m asin g-m asin g akar kata dalam dok um en tersebut.
137
2. Web S erver System Sistem ini merup akan sistem yang mener ima inp ut dari user berupa strin g query, yan g ak an dilanjutkan untuk mengh asilkan dok umen yang diin gink an. Pada sistem ini, web server akan membuka session dan kemudian mengirimkan strin g query m en uju ke Application Server. Web Server dan Applica tion Server dipisahkan dengan tujuan ketika ada banyak request qu ery yang masuk melalui user, tidak m engakibatkan keterlam batan dari request tersebut.
G am bar 3.9 Diagram Proses dari Web Server System Hasil pencarian dok umen ditam pilkan ber dasarkan ur utan bo bot, dan y an g paling
besar
bobotnya diletakkan
di palin g
atas.
Bobot
tersebut
merepresentasikan seberapa banyak dok um en tersebut berkaitan den gan kata kunci yan g dicari.
138
3. Applica tion Server S ystem Sistem ini akan melak ukan pengolahan terhadap strin g query yan g dimasukkan oleh u ser m elalui web server. Disini akan dilak ukan pa rsing dari query, optim asi dari query, yang kem udian akan dikirimkan m enuju server untuk me-retrieve h asil.
Gambar 3.10 Diagram Proses dari Applica tio n Server System
139
Di dalam application server pro ses-pro ses yang terjadi adalah mengh ilan gkan stop words p ada query, menghilan gkan tanda baca, melakukan tokenisasi, mengubah masin g-masin g token ke dalam akar kata dan m en gubah query k e dalam bent uk tree. Kem udian query siap untuk dieksek usi oleh inverted files system . 4. Inverted Files System Sistem ini adalah sistem yang melak ukan pek erjaan palin g banyak diban dingkan den gan sistem -sistem yang lainnya. Peran an utam a dipegan g oleh sistem ini, karena tanpa sistem ini tidak ada tem pat penyimpanan dan pengambilan data. Di sistem ini juga, pen gaturan da tabase objek diolah.
140
G am bar 3.11 Diagram Proses dari Proses Insert Inverted Files System Pada saat m em asukkan dokum en ke dalam database, dokumen yang sudah diin dex diolah dan sistem mencari dokum en- dok umen pada repository yan g berk aitan dengan token yang terkan dun g di dalam dok umen yang ak an dimasukkan. Kem udian dari masing-masin g dokumen ber dasark an token tersebut bo botnya dihit un g ulan g dan diur utkan berdasark an besar bobot dalam setiap dokumen berdasarkan token tersebut. Data dimasukkan k e dalam database dalam bent uk object.
141
Gambar 3.12 Diagram Proses dari Proses Delete Inverted Files System Pada saat dok um en akan dihap us dari database, terlebih dahulu dokumen tersebut diekstrak token-tokennya untuk k emudian dicari datanya di dalam database ber dasarkan m asing-masing token yan g terkandung di dalam dok um en tersebut dan penghapusan dok um en dilak ukan pada masing-masin g token. Setelah pengh ap usan dilakuk an database di-defrag agar berkas file yang telah dihapus dih ilan gk an dari database.
142
Database Database Database
G am bar 3.13 Diagram Proses dari Proses Query Inverted Files System Inverted files system m elakukan query setelah query diolah terlebih dah ulu k e dalam bent uk tree. Kem udian dar i masin g-masin g kata k unci di dalam query tersebut dicari hasilny a ke dalam database dan hasilnya di evaluasi berdasarkan op erator yan g terkan dun g di dalam kata k unci, setelah it u hasilnya siap unt uk ditampilkan.
143
3.4. 1 Indexer System Sistem ini merupakan sistem yang berh ubun gan lan gsung den gan Administrato r sebagai pen gakses seluruh kegiatan di dalam nya.
Initial Use Ca se yang kam i rancan g, adalah sebagai berikut:
Gambar 3.14 Initial Use Case da ri Ind exer System
144
Gambar di atas men unjukkan tahapan palin g awal k etika kita sedan g m endefin isikan sistem ini. Kem udian dilanjutkan den gan elaborasi dari use case yang sederh ana di atas, guna m elihat sem ua kegiatan yang dilakuk an. Seh ingga hasil elaborasinya adalah sebagai berik ut:
Gambar 3.15 Use Ca se Indexer System
145
Dari Use Case Indexer System ini, kita akan melihat lebih dalam setiap pro ses yang ada ke dalam Use Ca se Descrip tion-nya.
Ta bel 3.1 Deskripsi Elaborasi Use Case Melakukan Login Use C ase Name:
Melakukan login
Primary Actor(s):
Administrator
Secondary Actor(s):
-
Brief Description:
Users melakukan login untuk proses autentikasi
Pre conditions:
Users belum lo gin 1. Administrator m emasukkan username dan
Flow of Events:
password serta m enekan tom bol “login” 2. Sistem m elakuk an authentication terhadap username dan p asswor d 3. Jika user s valid, sistem m enampilkan m enu utama sesuai dengan h ak akses users Post conditions:
User yang berh ak akses telah terautentikasi
Priority:
High
Alternative Flow and Jika usern ame dan password tidak sesuai dengan yang Exceptions:
ada tersim pan pada database, maka sistem m em berikan warning message
Non
behavioral
-
requirements: -
Issues:
Kem udian, dari deskripsi use case yan g dijelaskan di atas, kita akan mencari kandidat objek dar i use case tersebut. 1. Potential Object List -
Authentication
146
-
Administrator
-
Users
-
Proses autentikasi
-
Usernam e
-
Passwor d
-
Tombol “login”
-
Sistem
-
Authentication
-
W arning Message
2. Proposed Object List -
Authentication
-
Tombol “login”
-
Users
Dari Object List yang dipero leh, selanjutnya kita m elakukan analisis interak si antar
objeknya
menggunakan
interaction
diagram.
Disin i
digun akan
collaboration diagram untuk m engerjakannya.
Gambar 3.16 Collaboration Diagram Use Case Melakukan Login
147
Ta bel 3.2 Deskripsi Elaborasi Use Case Mem ilih Dokumen Use C ase Name:
Memilih dokumen yang akan diindeks
Primary Actor(s):
Administrator
Secondary Actor(s):
-
Brief Description:
Administrator memilih dok umen yang akan diproses untuk pengindeksan.
Pre conditions:
Ketersediaan dok um en untuk di-indeks, dokumen harus m er upakan web-H TML do cument. 1. Adm inistrator mem ilih dokum en yan g akan di-
Flow of Events:
indeks, dan memastikan dok umen yang dipilih adalah web- HTML do cum ent. 2. Adm inistrator
m engaktivasi
f unction
FileSelection melalui tombol “select” untuk mem asukkan dokumen yan g di in dek s ke dalam list dokumen Post conditions:
Dok um en yan g terpilih ter sedia di dalam list
Priority:
High
Alternative Flow and Jika dokumen bukan dokum en HTML, m aka Show Exceptions: Non
behavioral
Warning Message -
requirements: -
Issues:
Dari deskr ipsi use case, k ita m encari kan didat objek dar i use case tersebut. 1. Potential Object List ‐
Dokumen
‐
Administrator
‐
Pengindeksan
148
‐
Indeks
‐
Web-HTML Document
‐
Sistem
‐
File Selection
‐
Tombol “select”
‐
List dok um en
‐
Warning Message
2. Proposed Object List ‐
List dok um en
‐
File selection
‐
Tombol “select”
Dari Object List yan g diperoleh, selanjutnya kita m em buat co llabor ation diagramnya.
G am bar 3.17 C ollaboration Diagram Use Case Memilih Dokumen
149
Ta bel 3.3 Deskripsi Elaborasi Use Case Melakukan Parsing Use C ase Name:
Melakukan parsing dari Web-HTML Docum ent ke Full Text Docum ent
Primary Actor(s):
Administrator
Secondary Actor(s):
-
Brief Description:
Administrator melakukan proses par sing terhadap webHTML docum ent yan g ak an di indeks m enjadi f ull text docum ent yait u m elip uti p en ghilangan tag-tag H TML, pem rosesan section dari script language dan konversi menjadi lowercase.
Pre conditions:
Dokumen yang akan diin deks harus tersedia di dalam list dok um en
Flow of Events:
1. Administrator m elakuk an
aktivasi function
parsing dengan m enek an tom bol “Parse” 2. Sistem mengambil dokum en dari list dokumen yang telah di proses pada saat pemilihan dok um en 3. Sistem m elakukan pen ghap usan tag HTML yang m en ghasilkan dokumen tanpa tag 4. Sistem m elakukan pem rosesan section pada script language untuk diambil kontennya yang termasuk r epresentasi dari dok umen sehin gga memberikan hasil dokum en representatif 5. Sistem m engkonversi dokum en representative menjadi f ull text do cum ent den gan mengubah seluruh isinya menjadi lo wer case. 6. Full
text
document
terbentuk
dan
siap
dik irim kan ke pen gin dek san tahap pertam a Post conditions:
Dok um en
hasil
parsin g
pengin dek san tahap pertama Priority:
High
akan
siap
untuk
ke
150
Alternative Flow and Parsin g hany a bisa dilak ukan kepada dok umen dengan Exceptions:
format HTML. Jika input dok umen yang dim asukkan bukan HTML maka sistem ak an menolak untuk m em proses dan mem ber ikan warnin g m essage.
Non
behavioral
-
requirements: Issues:
-
Dari deskr ipsi use case, k ita mencari kandidat objek dari use case ter sebut. 1. Potential Object List ‐
W eb-HTML Do cum ent
‐
Full Text Docum ent
‐
Administrator
‐
Indek s
‐
Tag-tag HTML
‐
Section
‐
Script lan guage
‐
Lo wer case
‐
Dokumen
‐
Parsin g
‐
Tombol “Parse”
‐
List Dok umen
‐
Dokumen Tanpa Tag
‐
Dokumen Representatif
151
2. Proposed Object List ‐
Dok um en
‐
List Dokum en
‐
Parser
‐
Tombol “Parse”
Dari Object List yang diperoleh, selanjutnya kita membuat collabor ation diagr am nya.
Gambar 3.18 Collaboration Diagram Use Case Melakukan Parsing
Ta bel 3.4 Deskripsi Elaborasi Use Case Melakukan Pengindeksan 1 Use C ase Name:
Melakukan pengindeksan tahap pertama
Primary Actor(s):
Administrator
Secondary Actor(s):
-
Brief Description:
Administrator melak ukan proses pengindeksan tahap pertam a yaitu membuang stop words dan tanda baca, melakukan
tokenisasi,
melakukan
stemm ing,
menghitun g f rekuensi token (frequency counter), dan membentuk string XML dar i setiap list token hasil proses par sing.
152
Pre conditions:
Proses p arsin g dokumen har us sudah dilak ukan. 1. Administrator m em ulai proses p en gindeksan
Flow of Events:
dengan m enekan tombol “Start Indexing” 2. Sistem m elakukan aktivasi f ungsi stopwords remover dan punctuation rem over untuk proses pembuan gan stop wor ds & tanda baca dari
dok um en hasil par sin g m enghasilkan
disposed docum ent 3. Sistem mengerjakan proses tokenisasi dari dokumen yaitu pemotongan menjadi token sehin gga dihasilkan list token 4. Dari token-token itu, sistem akan m elak ukan stemming unt uk membentuk root word s. 5. Sistem m elakuk an proses pada root wo rds yaitu m elakuk an perhit un gan frek uensi token 6. Proses terakhir adalah sistem m engek sekusi function
XML
converter
yaitu
m engkonver sikan detail yang dip eroleh yaitu nama dokumen, token, dan frek uen sinya ke dalam bentuk string XML. Post conditions:
Hasil ber upa string XML yan g berisi nam a dok umen, token, dan frek uen sinya dar i pen gindeksan tahap pertama ini akan dik irim kan ke server. High
Priority: Alternative Flow and Exceptions: Non
behavioral
requirements: Issues:
-
-
Dari deskr ipsi use case, k ita mencari kandidat objek dari use case ter sebut.
153
1. Potential Object List ‐
Pengin deksan
‐
Administrator
‐
Stop W ords
‐
Tanda Baca
‐
Tokenisasi
‐
Stemm ing
‐
Frek uen si Token
‐
Frequen cy Co unter
‐
Strin g XML
‐
List Token
‐
Tombol “Start Indexin g”
‐
Stop W ords Remover
‐
Punctuation Remover
‐
Disposed Document
‐
Root W ords
‐
XML Converter
‐
Nam a Dok umen
‐
Server
2. Proposed Object List ‐
Tokenisasi
‐
Stemm ing
‐
Frequen cy Co unter
‐
Tombol “Start Indexin g”
154
‐
Stop Words Rem over
‐
Punctuation Rem over
‐
XML Converter
Dari Object List yan g diperoleh, selanjutnya kita m em buat co llabor ation diagramnya.
ca at ul lc q re eF
to
ke n
iz e ()
()
Gam bar 3.19 C ollaboration Diagram Use Case Melakukan Pengindeksan 1
Tabel 3.5 Deskripsi Elaborasi Use C ase Mengirim kan Hasil Use Case Name:
Mengirimkan hasil pengindeksan tahap pertama ke server
Prim ary Actor(s):
Administrator
Secondary Actor(s):
-
Brief Description:
Administrator m elak ukan pengujian koneksi ke server, apabila koneksi tidak berm asalah, m aka sistem akan m engirim kan string XM L ke serv er.
Pre conditions:
Hasil pen gin dek san tahap p ertama telah tersedia untuk
155
dik irim kan ke server 1. Administrator m elak ukan proses pen gir iman
Flow of Events:
den gan menekan tombol “send” 2. Sistem akan m asuk
ke
XM L con verter
kem udian men gir imkannya ke server. Post conditions:
Hasil p engindeksan terkir im ke serv er.
Priority:
High
Alternative Flow and Exceptions:
-
behavioral Komunikasi antar PC har us dipastikan tidak terham bat,
Non
requirements:
seperti adanya firewall dan sekuritas lainnya.
Issues:
-
Dari deskr ipsi use case, k ita m encari kan didat objek dar i use case tersebut. 1. Potential Object List ‐
Hasil Pengindeksan Tahap Pertam a
‐
Server
‐
Administrator
‐
Sistem
‐
Strin g XML
‐
Tombol “Send”
‐
Connection Tester
‐
XML Converter
‐
PC
‐
Firewall
‐
Sek uritas
2. Proposed Object List
156
‐
Tombol “Sen d”
‐
XML Converter
Dari Object List yan g diperoleh, selanjutnya kita m em buat co llabor ation diagramnya.
Gambar 3.20 Collaboration Diagram Use Case Mengirimkan H asil
Tabel 3.6 Deskripsi Elaborasi Use C ase Menghilangkan Tag Use Case Name:
Menghilangkan tag
Description:
Sistem melakukan proses pengh ap usan sem ua tag dalam dokumen
Pre conditions: Flow of Events:
Dokumen dari list dokumen 1. Sistem melakuk an scanning dari dok umen secara sek uen sial 2. Sistem menjalankan f unction parsing untuk m enghap us sem ua tag yang ada di dalam keseluruhan dok umen
Post conditions:
Dokumen tanpa tag H TML
Alternative flows:
Jika tag berada pada -
bagian head, pada <meta> diam bil bagian description, keyword, dan title-nya
-
bagian head, pada
diambil
-
bagian body, ambil sem ua teks kecuali di dalam