Sistem Informasi Seminar Internasional ICO-APICT 2013

IMPLEMENTASI MULTI-AGENT PATH FINDING

MENGGUNAKAN ALGORITMA WHCA* PADA WEBOTS

SKRIPSI

Diajukan untuk Menempuh Ujian Akhir Sarjana

OLEH:

Fazhal Darul Farhi 10112901

PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS TEKNIK DAN ILMU KOMPUTER

UNIVERSITAS KOMPUTER INDONESIA 2015

iii

KATA PENGANTAR

Assalamualaikum Warahmatullahi Wabarakatuh.

Alhamdulillahi Robbil ’Alamin, puji dan syukur penulis panjatkan kehadirat

Allah Subhanahu wa Ta'ala atas berkat rahmat serta kasih-Nya sehingga penulis

dapat menyelesaikan skripsi ini dengan judul “IMPLEMENTASI MULTI-AGENT

PATH FINDING MENGGUNAKAN ALGORITMA WHCA* PADA WEBOTS“. Penulisan skripsi ini bertujuan untuk memenuhi sebagian syarat memperoleh gelar sarjana pendidikan bagi mahasiswa program S1 pada program studi Teknik Informatika Universitas Komputer Indonesia, Bandung. Penulis menyadari bahwa skripsi ini masih jauh dari kesempurnaan, oleh sebab itu penulis mengharapkan kritik dan saran yang bersifat membangun dari semua pihak demi kesempurnaan skripsi ini.

Selesainya skripsi ini tidak terlepas dari bantuan berbagai pihak, sehingga pada kesempatan ini penulis dengan segala kerendahan hati dan penuh rasa hormat mengucapkan terima kasih yang sebesar-besarnya kepada semua pihak yang telah memberikan bantuan moril maupun materil secara langsung maupun tidak langsung kepada penulis dalam penyusunan skripsi ini hingga selesai, terutama kepada yang saya hormati :

1. Yang tercinta ibunda dan ayahanda yang telah memberikan dorongan, mencurahkan segenap perhatian dan doa untuk keberhasilan penulis dan bantuannya dari segi moril maupun materil.

2. Bapak Irawan Afrianto, S.T., M.T., selaku Ketua Program Studi Teknik Informatika, Fakultas Teknik dan ilmu Komputer, UNIKOM.

3. Bapak Irfan Maliki, S.T., M.T., selaku dosen wali yang telah memberikan saran, arahan dan bimbingan kepada penulis.

4. Ibu Nelly Indriani Widiastuti, S.Si., M.T. selaku dosen pembimbing yang telah memberikan saran, arahan, dorongan dan bimbingan kepada penulis dalam menyelesaikan skripsi ini

5. Ibu Kania Evita Dewi., S.Pd., M.Si. selaku penguji satu yang telah memberikan saran, arahan dan bimbingan kepada penulis dalam menyelesaikan skripsi ini.

iv

6. Seluruh dosen pengajar dan staf UNIKOM yang telah membekali ilmu. 7. Teman-teman seperjuangan di Program Studi Teknik Informatika.

8. Terima kasih juga kepada semua pihak yang telah membantu dalam penyelesaian skripsi ini yang tidak dapat disebutkan satu per satu.

Akhir kata penulis mengucapkan terimakasih kepada semua pihak yang telah membantu dan penulis berharap semoga skripsi ini dapat bermanfaat bagi kita semua dan menjadi bahan masukan bagi dunia pendidikan.

Bandung, 28 Juli 2015

v ABSTRAK

ABSTRACT ... ii

KATA PENGANTAR ...iii

BAB 1 PENDAHULUAN ... 1

1.1.Latar Belakang Masalah ... 1

1.2. Rumusan Masalah ... 2

1.3. Maksud dan Tujuan ... 2

1.4. Batasan Masalah ... 2

1.5. Metodologi Penelitian ... 3

1.5.1. Metode Pengumpulan Data ... 3

1.5.2. Metode Pembangunan Perangkat Lunak ... 3

1.6. Sistematika Penulisan ... 4

BAB 2 TINJAUAN PUSTAKA ... 6

2.2. Mobile Robot ... 6

2.3. Pencarian Jalur Terpendek ... 7

2.4. Algortima A* ... 7

2.5. Cooperative A* ... 9

2.6. HPA* (Hierarchical Pathfinding A*) ... 10

2.6.1. Pre-processing grid... 11

2.6.2. Online Search ... 11

2.7. WHCA* (Windowed Hierarchical Cooperative A*) ... 12

2.8. UML (Unified Modeling Language) ... 14

2.8.1 Usecase Diagram... 14

2.8.2 Activity Diagram... 15

2.8.3 Sequence Diagram ... 15

2.8.4. Class Diagram ... 16

2.8.5. Statechart Diagram ... 16

2.8.6. Collaboration Diagram ... 16

2.8.7. Component Diagram ... 16

2.8.8 Deployment Diagram ... 17

2.9. Pengujian Perangkat Lunak ... 17

vi

3.1. Analisis Masalah ... 18

3.2. Analisis Masukan ... 18

3.3. Analisis Algoritma ... 19

3.3.1. Block Diagram Algoritma WHCA... 19

3.3.2. Contoh kasus ... 20

3.3 Analisis Perangkat Keras ... 36

3.4 Analisis Perangkat Lunak ... 36

3.5 Analisis Kebutuhan Fungsional ... 37

3.5.1. Usecase Diagram... 37

3.5.2. Skenario Use Case ... 37

3.5.3. Activity Diagram... 40

3.5.4. Class Diagram ... 44

3.5.5. Sequence Diagram ... 45

BAB 4 IMPLEMENTASI DAN PENGUJIAN ... 48

4.1. Implementasi ... 48

4.1.1. Implementasi Antarmuka ... 49

4.1.2. Implementasi Contoh Kasus Jalur WHCA* ... 49

4.2. Pengujian... 50

4.2.1. Pengujian blackbox ... 50

4.2.2. Rencana pengujian program simulasi ... 50

4.2.3. Kasus dan hasil pengujian ... 51

4.2.4. Pengujian Performansi ... 53

4.2.5. Kesimpulan Pengujian Blackbox ... 54

BAB 5 KESIMPULAN DAN SARAN ... 55

5.1. Kesimpulan ... 55

5.2. Saran ... 55

1 1.1. Latar Belakang Masalah

Di dalam industri, untuk menyusun barang dalam gudang yang besar membutuhkan banyak manusia. Manusia bertugas untuk menyusun barang dari tempat hasil produksi yang akan disimpan dan disusun sesuai dengan barang yang akan disimpan dan disusun. Perkembangan mobile robot dewasa ini sangat pesat, beriringan dengan kebutuhan akan tenaga – tenaga pembantu manusia yang cepat dan handal, salah satunya webots, yaitu mobile robot yang ciri khasnya adalah mempunyai aktuator berupa roda untuk menggerakan keseluruhan badan robot sehingga robot tersebut dapat melakukan perpindahan posisi dari satu titik ke titik lainnya. Dalam perkembangannya mobile robot dapat digunakan dalam suatu industri, dengan adanya mobile robot maka proses distribusi dalam industri akan lebih cepat. Untuk menjadi lebih cepat dalam mencapai tujuannya mobile robot harus dapat menghindari rute – rute yang dapat menyebabkan tabrakan atau menghindari hambatan. Berdasarkan hal tersebut dibutuhkan sebuah metode atau algoritma pencarian jalur terpendek dan agent harus menghindari rute yang dapat menyebabkan tabrakan dengan agent lainnya.

Saat ini ada beberapa algoritma yang dapat digunakan pada pencarian jalur terpendek dengan banyak agent, yaitu Hierarchical Cooperative A* (HCA*) dan Local Repair A* (LRA*). Tetapi ada beberapa masalah pada algoritma HCA* dan LRA*, pertama adalah ketika salah satu agent berakhir pada suatu node dan mungkin menghambat agent lain untuk bergerak. Idealnya setiap agent dapat mencapai tujuannya dan tidak menghambat jalur agent lain. Isu kedua adalah kepekaan terhadap urutan agent, meskipun kadang memprioritaskan agent global, solusi yang lebih kuat adalah dengan secara dinamis urutan pencarian pada agent, sehingga setiap agent memiliki prioritas tinggi pada waktu yang singkat. WHCA* dikembangkan dengan ide yang serupa pada operasi pencarian jalur terpendek sebelumnya dengan melakukan pencarian secara kooperatif dengan limit pencarian pada jendela yang berjalan.

Algoritma Windowed Hierarchical Cooperative A* merupakan pengembangan algoritma A* dalam pencarian jalur terpendek dengan banyak agent yang mana setiap agent saling tukar informasi tentang rute yang akan dilalui sehingga tidak menyebabkan tabrakan antar agent dengan membatasi ruang-waktu pencarian mendalam untuk jendela yang dinamis, menyebarkan perhitungan selama durasi rute [1].

Tujuan pada penelitian ini adalah mengetahui performansi waktu pencarian, jarak dan simpul yang diperiksa dari titk awal menuju titik tujuan dengan algoritma WHCA* untuk mencari jalur terpendek dengan agent lebih dari satu. Berdasarkan

uraian latar belakang tersebut maka akan ditarik judul “IMPLEMENTASI MULTI

AGENT PATH FINDING MENGGUNAKAN ALGORITMA WHCA* PADA

WEBOTS”.

1.2. Rumusan Masalah

Berdasarkan latar belakang yang sebelumnya dipaparkan, maka rumusan masalah yang diajukan adalah bagaimana menerapkan algoritma WHCA* dalam mencari jalur terpendek pada simulasi agent pengelola barang di gudang dengan agent lebih dari satu.

1.3. Maksud dan Tujuan

Maksud dari penelitian ini adalah implementasi multi agent path finding menggunakan algoritma WHCA* dan akan disimulasikan pada agent pengelola barang di gudang. Tujuannya adalah mengetahui performansi waktu pencarian dan jumlah simpul yang diperiksa dari titik awal menuju titik tujuan dengan algoritma WHCA* untuk mencari jalur terpendek dengan agent lebih dari satu.

1.4. Batasan Masalah

Untuk menghindari penyimpangan pokok permasalahan dan untuk mempermudah dalam pembahasan penelitian ini, maka perlu adanya pembatasan masalah sehingga diharapkan pembahasan dapat dilakukan lebih mendalam dan terfokus. Adapun pembatasan masalah dalam pembahasan penelitian ini adalah sebagai berikut:

2. Skenario agent pengelola gudang diadaptasi dari lingkungan gudang PT. INDOMARCO PRISTAMA.

3. Implementasi berupa simulasi agent pengelola barang di gudang dengan multi agent.

4. Setiap unit memiliki titik awal dan titik tujuan yang berbeda dalam waktu yang sama.

1.5. Metodologi Penelitian

Metodologi penelitian merupakan suatu proses yang digunakan untuk memecahkan suatu masalah yang logis, dimana memerlukan data untuk mendukung terlaksnanya suatu penelitian. Metodologi penelitian yang akan digunakan yaitu menggunakan metodologi analisis deskriptif.

Analisa deskriptif adalah metode yang menggambarkan fakta-fakta dan informasi dalam situasi atau kejadian secara sistematis, faktual dan akurat.

1.5.1. Metode Pengumpulan Data

Metode pengumpulan data yang dilakukan adalah dengan tahapan sebagai berikut:

1. Studi literatur

Metode pengumpulan data dengan cara membaca dan mempelajari jurnal – jurnal ilmiah, buku – buku, arikel dan browsing internet yang berhubungan dengan masalah yang menjadi topik dalam penelitian ini, selanjutnya melakukan percobaan yang relevan dengan topik penelitian ini.

2. Interview

Merupakan metode pengumpulan data studi kasus dengan cara mengajukan pertanyaan secara langsung pada pihak – pihak yang mengetahui hal – hal tentang proses penyusunan barang di gudang PT. INDOMARCO PRISTAMA.

1.5.2. Metode Pembangunan Perangkat Lunak

Tahapan dalam pembuatan perangkat lunak ini akan menggunakan metode prototipe. Prototipe dimulai dengan pengumpulan persyaratan. Pengembang dan pelanggan bertemu dan mendefenisikan tujuan secara keseluruhan untuk perangkat lunak, mengidentifikasi persyaratan apa saja yang diketahui dan area garis besar

pada tujuan yang wajib. Setelah itu, sebuah design cepat kemudian dilaksanakan. Desain cepat berfokus pada reprentasi dari aspek-aspek perangkat lunak yang akan terlihat oleh pengguna. Prototipe ini lalu dievaluasi dan digunakan oleh pengguna untuk memperbaiki software yang dikembangkan sesuai dengan yang dibutuhkan pengguna. Iterasi ini dilakukan untuk memenuhi kebutuhan pelanggan, sementara pada saat yang sama memungkinkan pengembang untuk lebih memahami apa yang perlu dilakukan [4].

Gambar 1.1. Metode Prototipe 1.6. Sistematika Penulisan

Sistematika penulisan Tugas Akhir ini disusun untuk memberikan gambaran umum tentang penelitian dalam Tugas Akhir yang dijalankan. Sistematika penulisan Tugas Akhir ini adalah sebagai berikut:

BAB 1 PENDAHULUAN

Bab ini membahas tentang latar belakang masalah, rumusan masalah, maksud dan tujuan, batasan masalah, metodologi penelitian, dan sistematika penulisan.

BAB 2 TINJAUAN PUSTAKA

Bab ini membahas berbagai konsep dasar teori yang berkaitan dengan topik penelitian yang dilakukan dan hal-hal yang berguna dalam proses analisis permasalahan yaitu tentang implementasi multi agent path finding pada webots yang dalam hal ini menggunakan algoritma WHCA*. Konsep lainnya yaitu mobile robot,Webots dan konsep path finding .

Bab ini membahas mengenai analisis dan kebutuhan algoritma pada simulasi robot gudang dengan pendekatan lingkungan gudang di PT. INDOMARCO PRISTAMA, analisis bagaimana penerapan algoritma WHCA* pada simulasi yang akan diterapkan untuk multi agent path finding. Dalam tugas akhir ini analisis dan kebutuhan perangkat lunak dibangun dengan konsep simulasi.

BAB 4 IMPLEMENTASI DAN PENGUJIAN

Bab ini menjelaskan tentang implementasi dari analisis yang telah dilakukan, serta pengujian dari implementasi algoritma WHCA* yang telah dibuat. Melakukan pengujian terhadap simulasi dengan algoritma yang telah diimplementasikan menggunakan pengujian skenario.

BAB 5 KESIMPULAN DAN SARAN

Bab ini berisi kesimpulan dari pengujian dan implementasi algoritma WHCA* berdasarkan tujuan yang ingin dicapai sebelumnya dan memberikan masukan atau saran dari masalah-masalah yang ditemukan selama proses penelitian terhadap algoritma WHCA*.

6 TINJAUAN PUSTAKA 1.2. Mobile Robot

Mobile Robot adalah konstruksi robot yang ciri khasnya adalah mempunyai aktuator berupa roda untuk menggerakkan keseluruhan badan robot tersebut, sehingga robot tersebut dapat melakukan perpindahan posisi dari satu titik ke titik lain dengan bantuan navigasi. Ada banyak navigasi yang digunakan mobile robot, diantaranya [3]:

1. Manual Remote

Sebuah robot manual benar-benar dibawah kendali seorang sopir dengan joystick atau perangkat kontrol lainnya. Perangkat mungkin dihubungkan langsung ke robot, mungkin joystick nirkabel, atau mungkin menjadi aksesori ke komputer nirkabel atau pengendali lainnya. Sebuah robot tele-op'd biasanya digunakan untuk menjaga operator dari bahaya.

2. Guarded Tele-op

Sebuah robot guarded tele-op memiliki kemampuan untuk merasakan dan menghindari rintangan tetapi sebaliknya akan menavigasi sebagai penggerak, seperti robot di bawah manual tele-op. Jika ada beberapa robot mobile hanya menawarkan guarded tele-op Sliding.

3. Next-line

Beberapa Automated awal Dipandu Kendaraan (AGVs) adalah baris berikut mobile robot. Mereka mungkin mengikuti garis visual dicat atau tertanam di lantai atau langit-langit atau sebuah kabel listrik di lantai. Mereka tidak bisa mengelilingi hambatan, mereka hanya berhenti dan menunggu ketika sesuatu menghalangi jalan mereka. Banyak contoh dari kendaraan tersebut masih dijual, oleh Transbotics , FMC, Egemin, HK Systems dan perusahaan lainnya.

4. Autonomously Randomized Robot

Otonomi robot dengan gerakan acak pada dasarnya terpental dinding, baik dinding-dinding yang merasakan dengan bumper fisik seperti pembersih Roomba atau dengan sensor elektronik seperti mesin pemotong rumput Robotika Friendly.

Algoritma sederhana bump dan putar 30 derajat akhirnya mengarah ke jangkauan sebagian besar atau seluruh permukaan lantai atau halaman.

Robot mobil ini sangat disukai bagi orang yang mulai mempelajari robot. Hal ini karena membuat robot mobil tidak memerlukan kerja fisik yang berat. Untuk dapat membuat sebuah robot mobile minimal diperlukan pengetahuan tentang mikrokontroler dan sensor-sensor elektronik.

1.3. Pencarian Jalur Terpendek

Pencarian jalur/rute (pathfinding) adalah salah satu bidang penerapan yang sering ditangani oleh kecerdasan buatan khususnya dengan menggunakan algoritma pencarian. Penerapan yang dapat dilakukan dengan pathfinding antara lain adalah pencarian rute dalam suatu game dan pencarian jalan/rute pada suatu peta. Algoritma pencarian yang dipakai harus dapat mengenali jalan dan elemen peta yang tidak dapat dilewati. Sebuah algoritma pathfinding yang baik dapat bermanfaat untuk mendeteksi halangan/rintangan yang ada pada medan dan menemukan jalan menghindarinya, sehingga jalan yang ditempuh lebih pendek daripada yang seharusnya bila tidak menggunakan algoritma pathfinding [2].

1.4. Algortima A*

Algoritma A*, dapat juga disebut sebagai algoritma A Star, merupakan salah satu contoh algoritma pencarian yang cukup popular di dunia. Beberapa terminology dasar yang terdapat pada algoritma ini adalah starting point, simpul (nodes), A, open list, closed list, harga (cost), halangan (unwalkable).

Starting point adalah sebuat terminology untuk posisi awal pada sebuah benda. A adalah simpul yang sedang dijalankan dalam algoritma pencarian jalan terpendek. Simpul adalah petak-petak kecil sebagai representasi dari area pathfinding. Bentuknya dapat berupa persegi, lingkaran maupun segitiga. Open list adalah tempat menyimpan data simpul yang mungkin diakses dari starting point maupun simpul yang sedang dijalankan. Closed list adalah tempat menyimpan data simpul sebelum A yang juga merupakan bagian dari jalur terpendek yang btelah berhasil didapatkan. Harga (F) adalah nilai yang diperoleh dari penjumlahan nilai G, jumlah nilai tiap simpul dalam jalur terpendek dari starting point ke A, dan H, jumlah nilai perkiraan dari sebuah simpul ke simpul tujuan. Simpul tujuan yaitu simpul yang

dituju. Rintangan adalah sebuah atribut yang menyatakan bahwa sebuah simpul tidak dapat dilalui oleh A. Prinsip algoritma ini adalah mencari jalur terpendek dari sebuah simpul awal menuju simpul tujuan dengan memperhatikan harga (F) terkecil. Diawali dengan menempatkan A pada starting point, kemudian memasukan seluruh simpul yang bertetangga dan tidak memiliki atribut rintangan dengan A ke dalam open list. Kemudian mencari nilai H terkecil dari simpul-simpul dalam opn list tersebut. Kemudian memindahkan A ke simpul yang memiliki H terkecil. Simpul sebelum A disimpan sebagai parent dari A dan dimasukan ke dalam closed list. Jika terdapat simpul lain yang bertetangga dengan A (yang sudah berpindah) maka masukan simpul-simpul tersebut ke dalam open list. Setelah itu, bandingkan nilai G yang ada dengan nilai G sebelumnya (pada langkah awal, tidak perlu dilakukan perbandingan nilai G). Jika nilai G sebelumnya lebih kecil maka kembali ke posisi awal. Simpul yang pernah dicoba dimasukan ke dalam closed list. Hal tersebut dilakukan berulang-ulang hingga terdapat solusi atau tidak ada lagi simpul yang berada pada open list [2]. Fungsi heuristik untuk menghitung taksiran nilai yang diberikan pada simpul dapat dinnyatakan sebagai berikut:

f(i) = g(i) + hi), dimana f(i) = ongkos untuk simpul i

g(i) = ongkos mencapai simpul i dari akar

h(i) = ongkos mencapai simpul tujuan dari simpul i

Dibawah ini adalah contoh lingkungan A*.

1.5.Cooperative A*

Ketika melakukan pencarian jalur terpendek dengan satu unit berdasarkan peta, pencarian menggunakan dasar A* sangat memadai, tetapi ketika beberapa unit bergerak pada saat yang sama, pendekatan dasar A* tidak bisa terpecahkan. Cooperative A* (CA*) adalah algoritma baru untuk memecahkan pencarian jalur terpendek secara kooperatif. Tugas dipisahkan menjadi serangkaian pencarian agen tunggal. Pencarian individu dilakukan dalam tiga dimensi ruang-waktu dan memperhitungkan rute yang direncanakan oleh agen lainnya. Langkah menunggu termasuk dalam tindakan agen. Setelah rute masing-masing agen dihitung setiap node ditandai ke tabel reservasi. Setelah unit memilih jalan, perlu memastikan bahwa unit lain tahu untuk menghindari sel-sel di sepanjang jalan. Hal ini dicapai dengan menandai setiap sel dalam tabel reservasi. Ini adalah struktur data langsung berisi entri untuk setiap sel dari peta ruang-waktu. Setiap entri menentukan apakah sel yang sesuai tersedia atau dilindungi. Setelah entri dicadangkan adalah illegal untuk unit lain untuk pindah ke sel itu. Tindakan reservasi seperti kendala sementara, menghalangi dari lokasi untuk waktu langkah di masa depan. Menggunakan meja reservasi dan peta ruang-waktu, maka sistem dapat memecahkan masalah kooperatif jalur terpendek. Setiap unit mencari jalur terpendek dengan menggunakan ruang-waktu A* dan kemudian menandai jalan ke dalam tabel reservasi. Unit berikutnya menghindari sel yang telah ditandai.

Gambar 2.2. Contoh 2 unit Cooperative Pathfinding

Tetapi, dengan cara tabel reservasi tidak mencegah dua unit melintas melalui satu sama lain saling berhadapan. Jika satu unit dilindungi (x,y,t) dan (x+1,y,t+1), tidak ada yang menghentikan unit kedua dari pemesanan (x+1, y,t) dan (x, y, t+1). Masalah ini dapat dihindari dengan membuat dua pemesanan untuk

setiap lokasi yang terlibat dalam tindakan, satu per- t dan satu waktu t+1 atau tabrakan bisa diidentifikasi secara eksplisit.

Sebuah pertanyaan alami untuk bertanya tentang merintis pencarian jalur terpendek secara kooperatif adalah seberapa jauh ke depan agen dapat melihat? Untuk bekerja sama dengan sempurna melihat ke masa depan, agent perlu melihat sejauh jalan terpanjang. Tapi ini mungkin akan menjadi ratusan timesteps, Dan kejadian itu akan menghabiskan berapa banyak waktu. Ruang waktu A* akan perlu mencari peta yang lebih besar, karena semakin lama dimensi waktu, meja reservasi akan perlu menyimpan path untuk semua unit dengan ratusan langkah ke depan. Idealnya, agent harus memiliki beberapa batas atas berapa banyak kerjasama diperlukan dan hanya mencari ke masa depan. Perkiraan ini harus mempertimbangkan sifat peta dan jumlah unit di wilayah itu, sebuah untuk melintasi daerah rami, jembatan sempit mungkin akan tertunda jauh lebih lama dari unit dengan melewati jalur dengan dataran yang sepi.

Dalam algoritma Cooperative A* batas kedalaman, dalam pencarian secara kooperatif akan dilambangkan dengan d. untuk tujuan dari ilustrasi, diasumsikan bahwa d adalah konstan untuk semua unit, tapi ini tidak perlu terjadi. Kedalaman ruang-waktu A* terbatas untuk langkah-langkah d. jika tujuan belum pernah tercapai, maka jalan parsial dikembalikan. Unit dimulai mengikuti jalan parsial sampai diperlukan untuk menghitung yang baru [1].

1.6. HPA* (Hierarchical Pathfinding A*)

HPA* adalah studi rinci dari algoritma pathfinding hirarkis untuk merintis jalan pada peta game computer. Algoritma ini membagi tugas pencarian jalan menjadi dua tahap yaitu offline preprosesing dan online pathfinding [4] .

Grafik yang telah disarikan untuk online pencarian dibangun menggunakan informasi yang diambil dari masalah labirin untuk lebih detail bagaimana kerangka kerja untuke pencarian hirarkis dibangun (pre-prosesing) dan bagaimana digunakan dalam online pathfinding. Awalnya focus pada membangun hirarkis dua tingkat: satu tingkat rendah dan satu tingkat abstrak [5].

2.6.1. Pre-processing grid

Langkah pertama dalam membangun kerangka untuk hirarkis pencarian sebuah topologi abstraksi dari labirin. Labirin abstraksi digunakan untuk membangun grafik dalam pencarian hirarkis. Abstraksi topologi meliputi labirin dengan satu set persegi panjang daerah yang disebut cluster. Contoh, dalam grid 40 x 40 akan dikelompokan ke dalam 16 cluster dengan ukuran 10 x 10. Untuk setiap garis perbatasan Antara dua kelompok yang berdekatan diidentifikasi set pintu masuk yang menghubungkan mereka. Pintu masuk adalah maksimal hambatan bebas 8 segmen sepanjang perbatasan bersama dua cluster c1 dan c2 berdekatan, secara resmi didefinisikan sebagai berikut. Pertimbangkan dua baris yang berdekatan ubin l1 dan l2 di setiap cluster, yang menentukan tepi perbatasan Antara c1 dan c2. Untuk ubin t2 anggota l1 gabung l2, dengan definisi symm (t) sebagai ubin simetris t terhadap perbatasan antara c1 dan c2. Perhatikan bahwa t dan symm (t) yang berdekatan dan tidak pernah milik cluster yang sama. Pintu masuk adalah seperangkat ubin yang menghormati kondisi berikut:

1. Perbatasan keterbatasan kondisi: l1 dan l2. Kondisi ini menyatakan bahwa pintu masuk adalah de ned bersama dan tidak bisa melebihi perbatasan antara dua cluster yang berdekatan.

2. Kendala kondisi bebas: pintu masuk tidak mengandung ubin kendala 3. Kondisi maximality: pintu masuk diperpanjang di kedua arah sebagai

Selama kondisi sebelumnya tetap berlaku. 2.6.2. Online Search

Tahap pertama dari pencarian on-line menghubungkan posisi awal S ke perbatasan cluster yang mengandung S. Langkah ini selesai sementara memasukkan S ke grafik abstrak. Demikian pula, menghubungkan posisi tujuan G ke perbatasan klaster ditangani dengan memasukkan G ke dalam grafik abstrak. Setelah S dan G telah ditambahkan, kita menggunakan A * untuk mencari jalan antara S dan G dalam grafik abstrak. Ini adalah bagian yang paling penting dari pencarian on-line. Ini menyediakan jalur abstrak, bergerak sebenarnya dari S ke perbatasan cluster S, jalan abstrak cluster G, dan bergerak yang sebenarnya dari perbatasan cluster G. Dua langkah terakhir dari pencarian online adalah opsional:

1. Jalan-ulang nement dapat digunakan untuk mengkonversi jalur abstrak ke dalam urutan bergerak pada grid asli.

2. Jalur-smoothing dapat digunakan untuk meningkatkan kualitas jalan-ulang nementukan solusi.

Jalur abstrak dapat kembali ned dalam langkah pasca-pengolahan untuk mendapatkan rinci jalur dari S ke G. Bagi banyak real-time aplikasi nding path-, path lengkap tidak diperlukan hanya beberapa langkah pertama. Informasi ini memungkinkan karakter untuk mulai bergerak ke arah yang benar menuju tujuan. Sebaliknya, A * harus menyelesaikan pencarian dan menghasilkan seluruh jalan dari S ke G sebelum dapat menentukan pertama yang langkah karakter. Pertimbangkan domain di mana perubahan dinamis sering terjadi (misalnya, ada banyak unit mobile berkeliling). Dalam kasus seperti itu, setelah nding abstrak jalan, kita bisa kembali ne secara bertahap sebagai karakter menavigasi menuju tujuan. Jika jalan abstrak saat ini menjadi tidak valid, agen membuang itu dan mencari yang lain jalan abstrak. Tidak perlu untuk kembali ne jalan seluruh abstrak di muka.

1.7.WHCA* (Windowed Hierarchical Cooperative A*)

Salah satu masalah dengan algoritma sebelumnya adalah bagaimana algoritma hanya membatasi pada sekali pencarian agen mencapai tujuan. Jika agen duduk pada tujuan, misalnya dalam koridor yang sempit, maka mungkin blok dari bagian peta untuk agen lainnya. Idealnya, agen harus terus bekerja sama setelah mencapai tujuan, sehingga agen dapat bergerak dari tujuan dan memungkinkan orang lain untuk lulus. Isu kedua adalah kepekaan terhadap agen pemesanan. Meskipun kadang-kadang mungkin untuk memprioritaskan agen global solusi yang lebih kuat adalah untuk secara dinamis bervariasi urutan agen, sehingga setiap agen akan memiliki tertinggi prioritas untuk waktu singkat. Solusi kemudian dapat ditemukan yang akan dipecahkan dengan sewenang-wenang agen. Ketiga, algoritma sebelumnya harus menghitung lengkap rute ke tujuan dalam besar, tiga-dimensi ruang space. Dengan pencarian agen tunggal, perencanaan dan rencana eksekusi sering disisipkan untuk mencapai efisiensi yang lebih besar dengan menghindari kebutuhan untuk merencanakan kontinjensi jangka panjang yang tidak sebenarnya terjadi. WHCA * mengembangkan ide serupa untuk koperasi pencarian. Sebuah solusi sederhana untuk semua masalah ini adalah untuk jendela pencarian.

Pencarian koperasi terbatas pada kedalaman tetap ditentukan oleh jendela saat. Setiap agen pencarian untuk rute parsial untuk tujuan, dan kemudian mulai mengikuti rute. Secara berkala (misalnya ketika agen adalah setengah jalan melalui rute parsial) jendela digeser ke depan dan rute parsial baru dihitung. Untuk memastikan bahwa agen kepala di arah yang benar, hanya kedalaman pencarian koperasi terbatas pada kedalaman tetap, sementara pencarian abstrak dijalankan untuk kedalaman penuh. Sebuah jendela ukuran w dapat dilihat sebagai abstraksi menengah yang setara dengan negara ruang tingkat dasar untuk langkah-langkah w, dan kemudian setara dengan ruang negara tingkat abstrak untuk sisa pencarian. Dengan kata lain, agen lainnya hanya dipertimbangkan untuk langkah w (melalui meja reservasi) dan diabaikan untuk sisa pencarian.

Untuk mencari ini ruang pencarian baru efisien, trik sederhana dapat digunakan. Setelah langkah langkah w telah berlalu, agen diabaikan dan ruang pencarian menjadi identik dengan pencarian abstrak ruang. Ini berarti bahwa jarak abstrak menyediakan informasi yang sama seperti menyelesaikan pencarian. Untuk setiap node dicapai setelah langkah w tepi terminal khusus diperkenalkan, akan langsung dari Ni ke tujuan G, dengan biaya sama dengan jarak abstrak dari Ni ke G. Menggunakan ini trik, pencarian direduksi menjadi jendela w-langkah menggunakan heuristik jarak abstrak diperkenalkan untuk HCA *. Selain itu, pencarian berjendela dapat melanjutkan setelah agen telah mencapai tujuan. Tujuannya agen tidak lebih lama untuk mencapai tujuan, tetapi untuk menyelesaikan jendela melalui tepi terminal. Setiap urutan w bergerak akan demikian mencapai tujuan. Namun, WHCA * pencari akan efisien menemukan urutan biaya terendah. Urutan optimal ini merupakan rute parsial yang akan membawa agen yang paling dekat dengan-nya tujuan, dan sekali di sana untuk tinggal di tujuan untuk sebagai waktu sebanyak mungkin.

Secara umum , fungsi biaya tepi untuk WHCA * adalah:

Gambar 2.3. Biaya Tepi WHCA*

Sebuah keuntungan tambahan dari windowing adalah proses yangwaktu dapat tersebar di semua agen. Dengan mengejutkan jendela tepat, pencarian dapat

lancar disisipkan. Dengan agen n dan ukuran jendela w , menghitung ulang rute pada titik tengah dari setiap jendela, hanya 2n pencarian / w perlu dilakukan per giliran. Jika giliran terdiri dari banyak frame, maka pencarian resumable alami rusak lebih lanjut dan dapat tersebar di beberapa frame [1].

1.8. UML (Unified Modeling Language)

UML adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun sebuah sistem. UML adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya. UML adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat tool untuk mendukung pengembangan sistem tersebut. UML mulai diperkenalkan oleh Object Management Group, sebuah organisasi yang telah mengembangkan model, teknologi, dan standar OOP sejak tahun 1980- an. Sekarang UML sudah mulai banyak digunakan oleh para praktisi OOP. UML merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM.

UML mendefinisikan diagram-diagram sebagai berikut: 1. Use case diagram

2. Activity diagram 3. Sequence diagram 4. Class diagram 5. Statechart diagram 6. Collaboration diagram 7. Component diagram 2.8.1 Usecase Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari

sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan

“bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor

dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang atau sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

Use case diagram dapat sangat membantu menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case

untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal.

Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.

2.8.2 Activity Diagram

Activity diagram menggambarkan berbagai alur aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alur berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

Activity diagram merupakan state diagram khusus, dimana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

2.8.3 Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pemain, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan

2.8.4. Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

2.8.5. Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu.

Umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.

2.8.6. Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

2.8.7. Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time.

Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

2.8.8 Deployment Diagram

Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal.

Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini [6]. 1.9.Pengujian Perangkat Lunak

Pengujian perangkat lunak merupakan proses verifikasi dan validasi dari sebuah perangkat lunak [6]. Pengujian perangkat lunak juga mengidentifikasi kelemahan dan kesalahan dalam kode aplikasi yang harus diperbaiki. Pengujian perangkat lunak memiliki tiga tujuan penting yaitu: verifikasi, validasi dan menemukan cacat. Verifikasi adalah proses menegaskan bahwa perangkat lunak sudah memenuhi spesifikasi teknik. Validasi adalah proses menegaskan bahwa perangkat lunak memenuhi kebutuhan bisnis. Menemukan cacat artinya varians Antara hasil yang diharapkan dengan aktual.

2.9.1 Unit Testing

Unit Testing merupakan serangkaian tes yang berdiri sendiri. Setiap tes meneliti komponen individu yang baru atau telah dimodifikasi. Setiap tes memvalidasi modul tunggal, berdasarkan dokumen teknis yang dibangun untuk melakukan tugas tertentu. Unit testing berfokus pada fungsi dan kehandalan sebuah perangkat lunak. Satuan pengujian dilakukan di lingkungan tes sebelum integrasi sistem [6]

18

ANALISIS DAN KEBUTUHAN ALGORITMA

1.1. Analisis Masalah

Masalah yang diangkat dalam penulisan ini adalah penerapan algoritma WHCA* dengan multi-agent yang akan disimulasikan pada aplikasi dengan lingkungan yang diadaptasi dari gudang PT. INDOMARCO PRISTAMA. Pada gudang PT. INDOMARCO PRISTAMA terdapat banyak agent yang bertugas untuk menyusun dan mengantarkan barang dimana setiap agent memungkinkan terjadi tabrakan dalam mencapai tujuannya. Untuk itu dibutuhkan sebuah algoritma pencarian jalur terpendek yang dapat menghindari tabrakan antar agent. Algoritma WHCA* merupakan pengembangan dari algoritma A* yang dapat mengatasi permasalahan pencarian jalur terpendek dengan multi-agent dengan menggunakan reservasi tabel sebagai tempat penyimpanan informasi path yang akan dilalui oleh agent hingga ke tujuan. Dengan adanya reservasi tabel, setiap agent akan kooperatif memberikan informasi jalur yang akan dilalui. Disisi lain algoritma WHCA* dibutuhkan kedalaman dalam pencarian dan jumlah path yang akan di reservasi, oleh karena itu yang akan diteliti untuk mengukur efektifitas penggunaaan algoritma WHCA* adalah jumlah kedalaman ketika proses pencarian dan waktu eksekusi untuk pencarian solusi.

1.2. Analisis Masukan

Analisis masukan menjelaskan data masukan yang akan diperlukan dalam penerapan algoritma WHCA* pada webots. Analisis masukan yang dibutuhkan pada algoritma WHCA* yaitu posisi awal agent, posisi akhir agent, posisi halangan dan kedalaman pencarian. Sebelum menghitung menggunakan algoritma WCHA* akan dihitung dulu biaya (cost) sebenarnya yang terdapat pada jalur itu sendiri. Map yang digunakan pada simulasi ini dengan skala pixel yang berukuran lebar 400 pixel dan tinggi 600 pixel. Satu layer tersebut disimpan dalam grid (suatu kotak-kotak kecil) yang dinamis dimana user dapat menentukan jumlah gridnya. Setiap grid memiliki ukuran dengan lebar 20 pixel dan tinggi 20 pixel, contoh map dengan ukuran lebar 20 pixel dan tinggi 20 pixel dapat dilihat pada gambar 3.1 berikut:

Gambar 3.1. Keterangan ukuran layar

Untuk mempermudah perhitungan maka ada beberapa nilai yang akan disederhanakan. Pertama nilai simpul yang tadinya 20x20 pixel diubah menjadi 1x1, artinya jarak simpul 1 ke simpul lainnya adalah 1. Jadi setiap simpul memiliki cost yang sama yaitu 1 secara horizontal maupun vertikal. Pergerakan yang dilakukan hanya bisa diagonal dan vertikal .

1.3. Analisis Algoritma

3.3.1. Block Diagram Algoritma WHCA

3.3.2. Contoh kasus

Untuk lebih memahami algoritma WHCA*, bisa dilihat dari contoh kasus seperti terlihat pada Gambar 3.3. Diasumsikan dalam simulasi ada 2 mobile robot (warna biru dan merah ) yang memiliki goal masing – masing, selain itu juga ada tembok penghalang.

Gambar 3.3.Kondisi awal pencarian WHCA* Keterangan:

Agent 1 Agent 2 Goal 1 Goal 2

Proses pertama yang dilakukan adalah setiap mencari jalur terpendek dari node awal, penyimpanan node menggunakan tiga dimensi ruang-waktu (x,y,time).

Setelah melakuan perhitungan awal, dan path awal telah ditemukan, setiap agen pindah ke tujuan node terdekat, seperti gambar 3.4 berikut ini:

Gambar 3.4. Kondisi Awal dengan path yang akan dilalui

Pada iterasi ini algoritma whca* melakukan penambahan pada variable currentWindow menjadi currentWindow+1 dan currentTime menjadi currentTime +1, setelah itu langkah selanjutnya adalah mengecek ulang, apakah ada unit yang harus di kalkulasi ulang atau tidak, unit yang akan dicek diambil secara random berdasarkan currentWindow.

Tabel 3.1. Path Iterasi 0 CurrentWindow = 0

currentTime = 0 depth = 10

AGENT 1

1,1,0 H =17, F =17,

G = 0

0, 1, 1 G = 1, H = 18,

F =19

1, 0, 1 G = 1, H = 18,

F =19

1, 2, 1 G = 1, H = 16,

F =17

2, 1, 1 G = 1, H = 16,

F =17 0, 2, 2

G = 2, H = 17, F =19

1, 1, 2 G = 2, H = 17,

F =19

1, 3, 2 G = 2, H = 17

, F =19

2, 2, 2 G = 2, H = 15, F

=17

2, 0, 2 G = 2, H = 17,

F =19

2, 1, 2 G = 2, H = 16,

F =18 1, 2, 3

G = 3, H = 16, F =19

2, 1, 3 G = 3, H = 16, F

=19

3, 2, 3 G = 2, H = 14, F

=17

2, 2, 3 G = 3, H = 15, F

=18 2, 2, 4

G = 4, H = 15, F =19

3, 3, 4 G = 4, H = 13, F

=17

3, 2, 4 G = 4, H = 14, F

=18 3, 2, 5

g: 5.0, h: 14.0, f: 19.0

3, 4, 5 g: 5.0, h: 12.0, f:

17.0

4, 3, 5 g: 5.0, h: 14.0, f:

19.0

3, 3, 5 g: 5.0, h: 13.0, f:

18.0 (3, 3, 6)

g: 6.0, h: 13.0, f: 19.0

(3, 5, 6) g: 6.0, h: 11.0,

f: 17.0

(3, 4, 6) g: 6.0, h: 12.0,

f: 18.0 (2, 5, 7)

g: 7.0, h: 12.0, f: 19.0

(3, 4, 7), g: 7.0, h: 12.0,

f: 19.0

(3, 6, 7) g: 7.0, h: 12.0,

f: 19.0

(4, 5, 7) g: 7.0, h: 10.0,

f: 17.0

(3, 5, 7) g: 7.0, h: 11.0,

f: 18.0 (3, 5, 8)

g: 8.0, h: 11.0, f: 19.0

(4, 6, 8) g: 8.0, h: 11.0,

f: 19.0

(5, 5, 8), g: 8.0, h: 9.0, f:

17.0

(4, 5, 8) g: 8.0, h: 10.0, f:

18.0 (4, 5, 9)

g: 9.0, h: 10.0

(5, 6, 9) g: 9.0, h: 10.0,

f: 19.0

(6, 5, 9) g: 9.0, h: 8.0, f:

17.0

(5, 5, 9) g: 9.0, h: 9.0, f:

AGENT 2 (7, 1, 0), g: 0.0, h: 11.0, f:

11.0

(7, 0, 1), g: 1.0, h: 12.0, f:

13.0

(7, 2, 1), g: 1.0, h: 10.0

(7, 1, 1), g: 1.0, h: 11.0,

f: 12.0

(7, 1, 2), g: 2.0, h: 11.0, f:

13.0

(7, 3, 2), g: 2.0, h: 9.0,

f: 11.0

(7, 2, 2), g: 2.0, h: 10.0,

f: 12.0

(7, 2, 3) , g: 3.0, h: 10.0, f:

13.0

(8, 3, 3), g: 3.0, h: 8.0,

f: 11.0

(7, 3, 3), g: 3.0, h: 9.0, f:

12.0

(7, 3, 4), g: 4.0, h: 9.0, f:

13.0

(9, 3, 4), g: 4.0, h: 7.0,

f: 11.0

(8, 3, 4) g: 4.0, h: 8.0,

f: 12.0,

(8, 3, 5), g: 5.0, h: 8.0, f:

13.0

(9, 2, 5), g: 5.0, h: 8.0,

f: 13.0

(9, 4, 5), g: 5.0, h: 6.0,

f: 11.0

(10, 3, 5), g: 5.0, h: 8.0,

f: 13.0

(9, 3, 5), g: 5.0, h: 7.0,

f: 12.0

(9, 3, 6), g: 6.0, h: 7.0, f: 13.0

(9, 5, 6), g: 6.0, h: 5.0, f:

11.0

(10, 4, 6), g: 6.0, h: 7.0,

f: 13.0

(9, 4, 6), g: 6.0, h: 6.0,

f: 12.0 (8, 5, 7),

g: 7.0, h: 4.0, f: 11.0

(9, 4, 7) g: 7.0, h: 6.0,

f: 13.0

(9, 6, 7) g: 7.0, h: 6.0,

f: 13.0

(10, 5, 7) g: 7.0, h: 6.0,

f: 13.0

(9, 5, 7) g: 7.0, h: 5.0

, f: 12.0 (7, 5, 8),

g: 8.0, h: 3.0, f: 11.0

(8, 6, 8), g: 8.0, h: 5.0,

f: 13.0

(9, 5, 8), g: 8.0, h: 5.0,

f: 13.0

(8, 5, 8), g: 8.0, h: 4.0,

f: 12.0

(7, 6, 9), g: 9.0, h: 4.0,

f: 13.0

(8, 5, 9), g: 9.0, h: 4.0,

f: 13.0

(7, 0, 2), g: 2.0, h: 12.0,

f: 14.0 (7, 1, 3), g: 3.0, h: 11.0,

f: 14.0 (7, 2, 4) g: 4.0, h: 10.0,

f: 14.0 (7, 3, 5) g: 5.0, h: 9.0,

f: 14.0,

(10, 3, 6), g: 6.0, h: 8.0,

f: 14.0 (8, 3, 6),

g: 6.0, h: 8.0, f: 14.0

(9, 2, 6), g: 6.0, h: 8.0, f:

14.0

(9, 5, 9) g: 9.0, h: 5.0,

f: 14.0

(8, 6, 9), g: 9.0, h: 5.0,

f: 14.0

(9, 3, 7), g: 7.0, h: 7.0, f:

14.0

(10, 4, 7), g: 7.0, h: 7.0,

f: 14.0 (9, 4, 8),

g: 8.0, h: 6.0, f: 14.0

(9, 6, 8), g: 8.0, h: 6.0,

f: 14.0 (10, 5, 8),

g: 8.0, h: 6.0, f: 14.0

Langkah selanjutnya adalah memindahkan posisi awal semua unit ke posisi node pada path selanjutnya. seperti gambar 3.5 dibawah ini:

Langkah selanjutnya melakukan check nilai currentWindow pada saat ini, dan mengecek apakah ada unit yang perlu di kalkulasi, jika ada maka lakukan pencarian path kembali dari posisi node yang terakhir. Penentuan posisi unit pada window ditentukan dengan rumus nilai depth/2/jumlah unit.

Tabel 3.2. Path iterasi 1 CurrentWindow = 1

currentTime = 1 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi, path sesuai dengan path sebelumnya

Tabel 3.3. Path iterasi 2 CurrentWindow = 2

currentTime = 2 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi, path sesuai dengan path sebelumnya

Gambar 3.6.kondisi agents iterasi 2

Tabel 3.4. Path iterasi ke 3 CurrentWindow = 3

currentTime = 3 depth = 10

AGENT 1

Path sesuai dengan jalur sebelumnya, karena agent 1 tidak melakukan repath.

AGENT 2

(8, 3, 3), g: 3.0, h: 8.0,

f: 11.0

(7, 3, 4), g: 4.0, h: 9.0, f:

13.0

(9, 3, 4), g: 4.0, h: 7.0, f: 11.0

(8, 3, 4) , g: 4.0, h: 8.0,

f: 12.0,

(8, 3, 5), g: 5.0, h: 8.0,

f: 13.0

(9, 2, 5), g: 5.0, h: 8.0,

f: 13.0

(9, 4, 5), g: 5.0, h: 6.0,

f: 11.0

(10, 3, 5), g: 5.0, h: 8.0,

f: 13.0

(9, 3, 5), g: 5.0, h: 7.0,

f: 12.0

(9, 3, 6), g: 6.0, h: 7.0,

f: 13.0

(9, 5, 6), g: 6.0, h: 5.0,

f: 11.0

(10, 4, 6), g: 6.0, h: 7.0,

f: 13.0

(9, 4, 6), g: 6.0, h: 6.0,

f: 12.0

(8, 5, 7), g: 7.0, h: 4.0,

f: 11.0

(9, 4, 7), g: 7.0, h: 6.0, f: 13.0

(9, 6, 7), g: 7.0, h: 6.0, f: 13.0

(10, 5, 7), g: 7.0, h: 6.0,

f: 13.0

(9, 5, 7), g: 7.0, h: 5.0

, f: 12.0

(7, 5, 8), g: 8.0, h: 3.0,

f: 11.0

(8, 6, 8), g: 8.0, h: 5.0,

f: 13.0

(9, 5, 8), g: 8.0, h: 5.0

f: 13.0

(8, 5, 8), g: 8.0, h: 4.0,

f: 12.0

(7, 6, 9), g: 9.0, h: 4.0,

f: 13.0

(8, 5, 9), g: 9.0, h: 4.0,

f: 13.0

(7, 3, 5) , g: 5.0, h: 9.0, f:

14.0,

(10, 3, 6), g: 6.0, h: 8.0,

f: 14.0 (8, 3, 6),

g: 6.0, h: 8.0, f: 14.0

(9, 2, 6), g: 6.0, h: 8.0, f:

14.0

(9, 5, 9) , g: 9.0, h: 5.0,

f: 14.0

(8, 6, 9), g: 9.0, h: 5.0,

f: 14.0,

(9, 3, 7), g: 7.0, h: 7.0

, f: 14.0

(10, 4, 7), g: 7.0, h: 7.0,

f: 14.0 (9, 4, 8),

g: 8.0, h: 6.0, f: 14.0

(9, 6, 8), g: 8.0, h: 6.0,

f: 14.0 (10, 5, 8),

g: 8.0, h: 6.0, f: 14.0

(9, 5, 10) g: 10.0, h: 5.0,

f: 15.0

(5, 6, 11), g: 11.0, h: 2.0,

f: 13.0

(6, 5, 11), g: 11.0, h: 2.0,

f: 13.0

(7, 6, 11), g: 11.0, h: 4.0,

f: 15.0

(6, 6, 11), g: 11.0, h: 3.0,

f: 14.0

(4, 6, 12), g: 9.0, h: 1.0,

f: 10.0

(5, 5, 12), g: 9.0, h: 1.0,

f: 10.0

(6, 6, 12), g: 9.0, h: 3.0,

Gambar 3.7. kondisi agents iterasi 3 Tabel 3.5. Path iterasi 4 CurrentWindow = 4

currentTime = 4 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi

Gambar 3.8.Kondisi agents iterasi 4

Dikarenakan currentWindow = (depth/2) maka currentWindow kembali menjadi 0 dan agent 1 akan menjadi prioritas pencarian jalur terpendek karena agent 1 berada pada posisi array ke-0 pada window.

Tabel 3.6. Path iterasi 5 CurrentWindow = 0

currentTime = 5 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi

Gambar 3.9. Kondisi Agents Iterasi 5

Tabel 3.7. Path iterasi 6 CurrentWindow = 1

currentTime = 6 depth = 10

(3, 5, 6) g: 6.0, h: 11.0,

f: 17.0

(2, 5, 7), g: 7.0, h: 12.0,

f: 19.0

(3, 4, 7), g: 7.0, h: 12.0,

f: 19.0

(3, 6, 7), g: 7.0, h: 12.0,

f: 19.0

(4, 5, 7), g: 7.0, h: 10.0,

f: 17.0

(3, 5, 7), g: 7.0, h: 11.0,

f: 18.0 (3, 5, 8),

g: 8.0, h: 11.0, f: 19.0

(4, 6, 8) g: 8.0, h: 11.0,

f: 19.0

(5, 5, 8), g: 8.0, h: 9.0,

f: 17.0

(4, 5, 8), g: 8.0, h: 10.0,

f: 18.0 (4, 5, 9),

g: 9.0, h: 10.0

(5, 6, 9), g: 9.0, h: 10.0,

f: 19.0

(6, 5, 9), g: 9.0, h: 8.0,

f: 17.0

(5, 5, 9), g: 9.0, h: 9.0,

f: 18.0 (5, 5, 10),

g: 10.0, h: 9.0, f: 19.0

(6, 6, 10), g: 10.0, h: 9.0,

f: 19.0

(7, 5, 10), g: 10.0, h: 7.0,

f: 17.0,

(6, 5, 10), g: 10.0, h: 8.0,

f: 18.0 (6, 5, 11),

g: 11.0, h: 8.0, f: 19.0

(7, 6, 11), g: 11.0, h: 8.0,

f: 19.0

(8, 5, 11), g: 11.0, h: 6.0,

f: 17.0

(7, 5, 11), g: 11.0, h: 7.0,

f: 18.0 (7, 5, 12)

g: 12.0, h: 7.0, f: 19.0

(8, 6, 12) g: 12.0, h: 7.0,

f: 19.0

(9, 5, 12) g: 12.0, h: 5.0,

f: 17.0

(8, 5, 12) g: 12.0, h: 6.0,

f: 18.0 (8, 5, 13)

g: 7.0, h: 6.0, f: 13.0

(9, 4, 13) g: 7.0, h: 4.0,

f: 11.0

(9, 6, 13) g: 7.0, h: 6.0,

f: 13.0

(10, 5, 13) g: 7.0, h: 6.0,

f: 13.0

(9, 5, 13) g: 7.0, h: 5.0,

f: 12.0 (9, 5, 14)

g: 8.0, h: 5.0, f: 13.0

(10, 4, 14) g: 8.0, h: 5.0,

f: 13.0

(9, 3, 14) g: 8.0, h: 3.0,

f: 11.0

(9, 4, 14) g: 8.0, h: 4.0,

f: 12.0 (9, 2, 15)

g: 9.0, h: 4.0, f: 13.0

(8, 3, 15) g: 9.0, h: 2.0,

f: 11.0

(9, 4, 15) g: 9.0, h: 4.0,

f: 13.0

(10, 3, 15) g: 9.0, h: 4.0,

f: 13.0

(9, 3, 15) g: 9.0, h: 3.0,

f: 12.0

AGENT 2

Path sesuai dengan jalur sebelumnya

Tabel 3.8. Path iterasi 7 CurrentWindow = 2

currentTime = 7 depth = 10

AGENT 1 AGENT 2

Gambar 3.10. kondisi agents iterasi 7

Tabel 3.9. Path iterasi 8 CurrentWindow = 3

currentTime = 8 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi

Gambar 3.11. kondisi agents iterasi 8 Tabel 3.10. Path iterasi 9 CurrentWindow = 4

currentTime = 9 depth = 10

AGENT 1

Unit tidak perlu dikalkulasi,karena prioritas pada iterasi ini adalah agent 2. Maka agent 2 melakukan kalkulasi ulang, path agen 1 masih sesuai dengan path sebelumnya.

(7, 6, 9), g: 9.0, h: 4.0, f: 13.0

(6, 6, 10) g: 1.0, h: 3.0,

f: 4.0

(8, 6, 10) g: 1.0, h: 5.0,

f: 6.0

(7, 6, 10) g: 1.0, h: 4.0,

f: 5.0

(5, 6, 11) g: 2.0, h: 2.0,

f: 4.0

(6, 5, 11) g: 2.0, h: 2.0,

f: 4.0

(7, 6, 11) g: 2.0, h: 4.0,

f: 6.0

(6, 6, 11) g: 2.0, h: 3.0,

f: 5.0

(5, 5, 12) g: 3.0, h: 1.0,

f: 4.0

(6, 6, 12) g: 3.0, h: 3.0,

f: 6.0

(7, 5, 12) g: 3.0, h: 3.0,

f: 6.0

(6, 5, 12) g: 3.0, h: 2.0,

f: 5.0

(4, 5, 13), g: 4.0, h: 0.0, f: 4.0

(5, 6, 13) g: 4.0, h: 2.0,

f: 6.0

(6, 5, 13) g: 4.0, h: 2.0,

f: 6.0

(5, 5, 13) g: 4.0, h: 1.0,

f: 5.0

(3, 5, 14) g: 5.0, h: 1.0,

f: 6.0

(4, 6, 14) g: 5.0, h: 1.0,

f: 6.0

(5, 5, 14) g: 5.0, h: 1.0,

f: 6.0

(4, 5, 14) g: 4.0, h: 0.0,

f: 4.0

(3, 5, 15) g: 5.0, h: 1.0,

f: 6.0

(4, 6, 15) g: 5.0, h: 1.0,

f: 6.0

(5, 5, 15) g: 5.0, h: 1.0,

f: 6.0

(4, 5, 15) g: 4.0, h: 0.0,

f: 4.0

(3, 5, 16) g: 5.0, h: 1.0,

f: 6.0

(4, 6, 16) g: 5.0, h: 1.0,

f: 6.0

(5, 5, 16) g: 5.0, h: 1.0,

f: 6.0

(4, 5, 16) g: 4.0, h: 0.0,

f: 4.0

(3, 5, 17), g: 5.0, h: 1.0,

f: 6.0

(4, 6, 17) g: 5.0, h: 1.0,

f: 6.0

(5, 5, 17) g: 5.0, h: 1.0,

f: 6.0

(4, 5, 17) g: 4.0, h: 0.0,

f: 4.0

(3, 5, 18) g: 5.0, h: 1.0, f: 6.0

(4, 6, 18) g: 5.0, h: 1.0,

f: 6.0

(5, 5, 18) g: 5.0, h: 1.0,

f: 6.0

(4, 5, 18) g: 4.0, h: 0.0,

f: 4.0

Tabel 3.11. Path iterasi 10 CurrentWindow = 0

currentTime = 10 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi, path masih sesuai dengan path sebelumnya

Gambar 3.13.Kondisi agents iterasi 10

Tabel 3.12. Path iterasi 11 CurrentWindow = 1

currentTime = 11 depth = 10

AGENT 1 AGENT 2

Gambar 3.14. Kondisi agents iterasi 11

Tabel 3.13. Path iterasi 12 CurrentWindow = 2

currentTime = 12 depth = 10

AGENT 1

(9, 5, 12) g: 12.0, h: 5.0,

f: 17.0 (8, 5, 13)

g: 7.0, h: 6.0, f: 13.0

(9, 4, 13) g: 7.0, h: 4.0,

f: 11.0

(9, 6, 13), g: 7.0, h: 6.0, f: 13.0

(10, 5, 13) g: 7.0, h: 6.0,

f: 13.0

(9, 5, 13) g: 7.0, h: 5.0,

f: 12.0 (9, 5, 14)

g: 8.0, h: 5.0, f: 13.0

(10, 4, 14) g: 8.0, h: 5.0,

f: 13.0

(9, 3, 14) g: 8.0, h: 3.0,

f: 11.0

(9, 4, 14) g: 8.0, h: 4.0,

f: 12.0 (9, 2, 15)

g: 9.0, h: 4.0, f: 13.0

(8, 3, 15) g: 9.0, h: 2.0,

f: 11.0

(9, 4, 15) g: 9.0, h: 4.0,

f: 13.0

(10, 3, 15) g: 9.0, h: 4.0,

f: 13.0

(9, 3, 15) g: 9.0, h: 3.0,

f: 12.0 (8, 3, 16)

g: 10.0, h: 2.0, f: 12.0

(9, 3, 16) g: 10.0, h: 3.0,

f: 13.0

(7, 3, 16) g: 10.0, h: 1.0,

f: 11.0

(7, 3, 17), g: 11.0, h: 1.0,

f: 12.0

(8, 3, 17), g: 11.0, h: 2.0,

f: 13.0

(7, 2, 17), g: 11.0, h: 0.0,

f: 11.0

(7, 3, 18), g: 12.0, h: 1.0,

f: 13.0

(7, 1, 18), g: 12.0, h: 1.0,

f: 13.0

(7, 2, 18), g: 11.0, h: 0.0,

f: 11.0

(7, 1, 19), g: 6.0, h: 1.0,

f: 7.0

(7, 3, 19), g: 6.0, h: 1.0,

f: 7.0

(7, 2, 19), g: 5.0, h: 0.0,

f: 5.0

(7, 1, 20), g: 6.0, h: 1.0,

f: 7.0

(7, 3, 20), g: 6.0, h: 1.0,

f: 7.0

(7, 2, 20), g: 5.0, h: 0.0,

f: 5.0

(7, 1, 21), g: 6.0, h: 1.0,

f: 7.0

(7, 3, 21), g: 6.0, h: 1.0,

f: 7.0

(7, 2, 21), g: 5.0, h: 0.0,

AGENT 2

Unit tidak perlu dikalkulasi,karena prioritas pada iterasi ini adalah agent 1. Maka agent 1 melakukan kalkulasi ulang, path agen 2 masih sesuai dengan path sebelumnya

Gambar 3.15. Kondisi agents iterasi 12

Tabel 3.14. Path iterasi 13 CurrentWindow = 3

currentTime = 13 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi, path masih sesuai dengan path sebelumnya

Tabel 3.15. Path iterasi 14 CurrentWindow = 4

currentTime = 14 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi, path masih sesuai dengan path sebelumnya

Gambar 3.17. Kondisi Agents iterasi 14

Tabel 3.16. Path iterasi 15 CurrentWindow = 0

currentTime = 15 depth = 10

(3, 5, 16), g: 5.0, h: 1.0,

f: 6.0

(4, 6, 16), g: 5.0, h: 1.0,

f: 6.0

(5, 5, 16), g: 5.0, h: 1.0,

f: 6.0

(4, 5, 16), g: 4.0, h: 0.0,

f: 4.0

(3, 5, 17), g: 5.0, h: 1.0,

f: 6.0

(4, 6, 17), g: 5.0, h: 1.0,

f: 6.0

(5, 5, 17), g: 5.0, h: 1.0,

f: 6.0

(4, 5, 17), g: 4.0, h: 0.0,

f: 4.0

(3, 5, 18), g: 5.0, h: 1.0,

f: 6.0

(4, 6, 18), g: 5.0, h: 1.0,

f: 6.0

(5, 5, 18), g: 5.0, h: 1.0,

f: 6.0

(4, 5, 18), g: 4.0, h: 0.0,

f: 4.0

(3, 5, 19), g: 5.0, h: 1.0,

f: 6.0

(4, 6, 19), g: 5.0, h: 1.0,

f: 6.0

(5, 5, 19), g: 5.0, h: 1.0,

f: 6.0

(4, 5, 19), g: 4.0, h: 0.0,

f: 4.0 (4, 5, 15),

g: 4.0, h: 0.0, f: 4.0

(3, 5, 20), g: 1.0, h: 1.0,

f: 2.0

(4, 6, 20), g: 1.0, h: 1.0,

f: 2.0

(5, 5, 20), g: 1.0, h: 1.0,

f: 2.0

(4, 5, 20), g: 0.0, h: 0.0,

f: 0.0

(3, 5, 21), g: 1.0, h: 1.0,

f: 2.0

(4, 6, 21), g: 1.0, h: 1.0,

f: 2.0

(5, 5, 21), g: 1.0, h: 1.0,

f: 2.0

(4, 5, 21), g: 0.0, h: 0.0,

f: 0.0

(3, 5, 22), g: 1.0, h: 1.0,

f: 2.0

(4, 6, 22), g: 1.0, h: 1.0,

f: 2.0

(5, 5, 22), g: 1.0, h: 1.0,

f: 2.0

(4, 5, 22), g: 0.0, h: 0.0,

f: 0.0

(3, 5, 23), g: 1.0, h: 1.0,

f: 2.0

(4, 6, 23), g: 1.0, h: 1.0,

f: 2.0

(5, 5, 23), g: 1.0, h: 1.0,

f: 2.0

(4, 5, 23), g: 0.0, h: 0.0,

f: 0.0

(3, 5, 24), g: 1.0, h: 1.0,

f: 2.0

(4, 6, 24), g: 1.0, h: 1.0,

f: 2.0

(5, 5, 24), g: 1.0, h: 1.0,

f: 2.0

(4, 5, 24), g: 0.0, h: 0.0,

f: 0.0

AGENT 2

Unit tidak perlu dikalkulasi,karena prioritas pada iterasi ini adalah agent 1. Maka

agent 1 melakukan kalkulasi ulang, pathagent 2 masih sesuai dengan path sebelumnya

Gambar 3.18. Kondisi agents iterasi 15

Tabel 3.17. Path iterasi 16 CurrentWindow = 1

currentTime = 16 depth = 10

AGENT 1 AGENT 2

Tidak ada unit yang perlu dikalkulasi, path masih sesuai dengan path sebelumnya

Gambar 3.19. Kondisi agents iterasi 16

Tabel 3.18. Path iterasi 17 CurrentWindow = 2

currentTime = 17 depth = 10

Semua unit sudah mencapai tujuannya masing-masing

Gambar 3.20. Kondisi agents iterasi 17

3.3 Analisis Perangkat Keras

Spesifikasi perangkat keras (hardware) yang dibutuhkan untuk menguji pengimplementasian algoritma WHCA* pada webots ini dapat dilihat pada Tabel 3.19.

Tabel 3.19. Kebutuhan Perangkat Keras

Perangkat Keras Spesifikasi

Processor Intel Core-i5-3230M 2.6 Ghz

Resolusi layar 1024 x 768 pixel

Memori 2 GB

Harddisk 500GB

3.4 Analisis Perangkat Lunak

Spesifikasi perangkat lunak (software) yang dibutuhkan untuk menguji pengimplementasian algoritma WHCA* pada webots ini dapat dilihat pada Tabel 3.20.

Tabel 3.20. Kebutuhan Perangkat Lunak

Komputer Spesifikasi

Sistem Operasi Windows 8

Bahasa Pemograman Java

3.5 Analisis Kebutuhan Fungsional

Analisis kebutuhan fungsional menggambarkan proses kegiatan yang akan diterapkan dalam sebuah sistem dan menjelaskan kebutuhan yang diperlukan sistem agar sistem dapat berjalan dengan baik sesuai kebutuhan. Analisis yang dilakukan dimodelkan dengan menggunakan UML (Unified Modeling Language). Tahapan pemodelan dalam analisis tersebut antara lain pembuatan use case diagram, definisi aktor, definisi use case, skenario use case, activity diagram, sequence diagram, dan class diagram.

1.5.1. Usecase Diagram

Use case diagram digunakan untuk memodelkan proses bisnis dan merepresentasikan sebuah interaksi antara aktor dengan sistem. Aktor disini adalah

pengguna, yang mana pengguna dapat menginput starting point dan end point dengan

unit yang banyak.

Gambar 3.21. Usecase Diagram WHCA*

3.5.2. Skenario Use Case

Skenario setiap bagian pada use case menunjukkan proses apa yang terjadi pada setiap bagian didalam use case tersebut, dimana pengguna memberikan perintah pada setiap bagian dan respon apa yang diberikan oleh sistem kepada

pengguna setelah pengguna memberikan perintah pada setiap bagian-bagian use case.

Tabel 3.21. Skenario Use Case Menambah Agent Identifikasi

Nama Menambah Agent

Tujuan Menginstrusikan program untuk

menambah agent

Deskripsi Inisiasi agent untuk proses pencarian

Aktor Pengguna

Skenario Utama

Kondisi Awal Pengguna berada di menu utama pada program

Aksi actor Reaksi Sistem

1. User memilih koordinat

2. User Menekan tombol tambah agent

3. Unit melakukan inisialisasi path 4. Sistem menampilkan unit pada

koordinat yang diinputkan Kondisi Akhir Sistem menampilkan agent pada

koordinat yang diinputkan

Tabel 3.22. Skenario Use Case Mencari jalur terpendek dengan WCHA* Identifikasi

Nama Mencari jalur terpendek dengan

WHCA*

Tujuan Menginstrusikan program untuk

pencarian jalur terpendek menggunakan WHCA*

Deskripsi Proses pencarian jalur terpendek

Aktor Sistem

Skenario Utama

Kondisi Awal Unit memiliki koordinat awal dan akhir

Aksi - Reaksi Sistem

-

1. Inisialisasi node awal dan node akhir 2. Sistem menyimpan node awal ke list

open

3. Melakukan iterasi tetangga dan melakukan validasi node tujuan 4. Sistem menampilkan path setiap

agent

Kondisi Akhir Agent memiliki path sampai tujuan dengan jalur yang unik, tanpa adanya kemungkinan tabrakan

Tabel 3.23.Skenario Use Case Reset agent Identifikasi

Nama Reset unit

Tujuan Menginstrusikan program untuk

me-reset ulang posisi agent

Deskripsi Proses reset agent

Aktor Sistem

Skenario Utama

Kondisi Awal Agent berada pada posisi pencarian

Aksi User Reaksi Sistem

1. Tekan tombol Reset 2. Sistem menampilkan agent pada posisi awal

Kondisi Akhir Agent kembali ke posisi awal

Tabel 3.24. Skenario Use Case Animateagent Identifikasi

Nama Animate unit

Tujuan Menginstrusikan program untuk

melakukan pencarian jalur terpendek dengan adanya animasi pada setiap pergerakan

Deskripsi Proses animasi pergerakan pencarian jalur terpendek

Aktor Sistem

Skenario Utama

Kondisi Awal Agent berada pada posisi awal

Aksi User Reaksi Sistem

1. Tekan tombol Animate 2. Agent melakukan pencarian dengan animasi pada setiap pergerakan

Kondisi Akhir Agent bergerak mencari jalur

Tabel 3.25. Skenario Use Case StopAgent Identifikasi

Nama Stop agent

Tujuan Menginstrusikan program untuk

berhenti dalam pergerakan mencari jalur terpendek

Deskripsi Proses melakukan berhenti dalam

pergerakan pencarian

Aktor Sistem

Skenario Utama

Kondisi Awal Agent berada pada koordinat tertentu

Aksi User Reaksi Sistem

1. Tekan tombol Stop 2. Menampilkan agent pada posisi diam dan koordinat terakhir

Kondisi Akhir Agent berhenti pada posisi terakhir

Tabel 3.26. Skenario Use Case Step Agent Identifikasi

Nama Step Agent

Tujuan Menginstrusikan program untuk maju

selangkah menuju node selanjutnya Deskripsi Proses melakukan perpindahan agent

dari node awal ke node selanjutnya

Aktor Sistem

Skenario Utama

Kondisi Awal Agent berada pada posisi awal

Aksi User Reaksi Sistem

1. Tekan tombol Step 2. Sistem menampilkan agent pada posisi selanjutnya

Kondisi Akhir Agent berada pada posisi node selanjutnya

Tabel 3.27. Skenario Use Case mengubah Grid Identifikasi

Nama Mengubah grid

Tujuan Menginstrusikan program untuk

mengubah jumlah kolom dan baris grid

Deskripsi Proses mengubah baris dan kolom grid

Aktor Sistem

Skenario Utama

Kondisi Awal Jumlah grid sesuai default

Aksi User Reaksi Sistem

1. mengisi data nilai kolom 2. Mengisi data nilai baris 3. Menekan tombol Grid Baru

4. Sistem menampilkan grid

Kondisi Akhir Jumlah kolom dan baris grid sesuai dengan yang diinputkan

3.5.3. Activity Diagram

Diagram aktivitas atau Activity Diagram menggambarkan workflow (aliran

kerja) atau aktivitas dari sebuah sistem atau proses bisnis. Penggambaran activity

diagram memiliki kemiripan dengan flowchart diagram. Activity diagram memodelkan

event-event yang terjadi pada Use Case dan digunakan untuk pemodelan aspek dinamis dari sistem.

Gambar 3.22. Activity Diagram Tambah Agent

Gambar 3.23. Activity Diagram Tombol Reset

Gambar 3.25.Activity Diagram Tombol Step

3.5.4. Class Diagram

3.5.5. Sequence Diagram

Diagram sequence atau Sequence Diagram menggambarkan kelakuan objek

pada use case dengan mendeskripsikan waktu hidup objek dan message yang

dikirimkan dan diterima antar objek.

Gambar 3.27.Sequence Diagram Tombol Stop

Gambar 3.29. Sequence Diagram Tombol Reset

Gambar 3.31. Sequence Diagram Menambah Agent

MAGALINE, F. (2012). Konsep Dasar Sistem Informasi. Jurnal Sistem Informasi , 1-3.

1

BAB I PENDAHULUAN

1.1

Latar Belakang Masalah

Informasi merupakan kebutuhan bagi setiap orang. Melalui teknologi informasi seseorang dapat memperoleh informasi dengan cepat dan mudah. Salah satu produk teknologi yang dapat digunakan sebagai sarana temu-balik informasi adalah website. UNIKOM (Universitas Komputer Indonesia) sebagai salah satu perguruan tinggi di Bandung, sering menggunakan website pada keseharian proses bisnisnya. Salah satunya untuk kegiatan ICO-APICT.

ICO-APICT merupakan seminar international yang diadakan oleh UNIKOM dengan tujuan merangkum gagasan penelitian serta untuk mempromosikan bentuk-bentuk implementasi nyata dari penggunaan dan peran ICT dalam bidang teknik, ekonomi, politik, hukum, sastra dan seni. Seminar ini diikuti oleh para pemakalah yang lebih dikenal dengan sebutan presenter.

Dalam penyelenggaraan Seminar Internasional ICO-APICT ini, dibutuhkan suatu sistem yang mendukung pengelolaan proses data seminar dengan cepat, akurat dan bersifat realtime. Hal ini dilakukan, demi tercapainya, penyelenggaraan seminar yang efisien dan efektif dalam penyajian informasi, sehingga dapat memenuhi kepuasan pelayanan kepada calon presenter. Sistem yang ditujukan untuk mendukung pengelolaan proses data seminar ini, akan dibuat dalam bentuk website untuk menyajikan informasi secara cepat, akurat dan realtime tentang seminar ini.

1.2 Identifikasi Masalah

Berdasarkan latar belakang masalah yang telah diuraikan di atas, yang menjadi titik permasalahan dalam laporan ini adalah sebagai berikut :

1. Media informasi bagi calon presenter seminar sangat terbatas. 2. Proses administrasi yang kurang efesien dan efektif.

1.3 Maksud dan Tujuan

Maksud dari laporan ini adalah membangun aplikasi mengenai sistem informasi seminar international. Sedangkan tujuan yang akan dicapai dalam penelitian ini adalah :

1. Calon presenter lebih mudah mendapatkan informasi. 2. Proses administrasi lebih efesien dan efektif.

1.4 Batasan Masalah

Mengingat permasalahan yang dikaji sangat luas, agar penyajian lebih terarah dan mencapai sasaran yang ditentukan, maka diperlukan suatu pembatasan masalah atau ruang lingkup kajian yang meliputi hal-hal sebagai berikut :

1. Target utama aplikasi ini adalah UNIKOM.

2. Aplikasi berjenis Sistem Informasi Akademik berbasis web. 3. Sistem Pengelolan Paper dan Media Informasi.

1.5 Metodologi Penelitian

Laporan ini menggunakan metode penelitian eksperimental, yaitu metode penelitian yang didasarkan pada suatu percobaan-percobaan ilmiah yang dilakukan dalam membuat sesuatu yang baru atau mengembangkan sesuatu berdasarkan ilmu-ilmu pengetahuan. Metode yang digunakan pada saat mengumpulkan data dan mengembangkan aplikasi sebagai berikut :

1. Metode Pengumpulan Data

Metode pengumpulan data yang digunakan dalam penelitian ini adalah dengan Pengumpulan data dengan cara mewawancarai salah satu panitia Seminar ICOAPICT 2013.

2. Metode Pembuatan Perangkat Lunak

Metode yang digunakan dalam pembuatan perangkat lunak ini akan menggunakan model waterfall. Model ini adalah model klasik yang melakukan pendekatan secara sistematis, berurutan dalam membangun software, berkat penurunan dari satu fase ke fase lainnya. Model ini dikenal sebagai model air

terjun atau siklus hidup perangkat lunak. Berikut ini adalah proses-proses model waterfall :

a. Communication

Tahap ini merupakan kegiatan berkomunikasi dan berkolaborasi dan lainnya. Tujuannnya adalah untuk memahami stakeholder, tujuan untuk proyek dan untuk mengumpulkan persyaratan yang membantu mendefinisikan fitur perangkat lunak dan fungsi.

b. Planning

Setiap perjalanan yang rumit dapat disederhanakan jika ada peta. Sebuah project software adalah sebuah perjalanan yang rumit, dan kegiatan perencanaan menciptakan “peta” membantu yang memandu tim karena membuat perjalanan. “Peta” disebut proyek perangkat lunak mendefinisikan rencana kerja software engineering dengan menjelaskan tugas-tugas teknis yang harus dilakukan, resiko yang mungkin, sumber daya yang akan diperlukan, produk pekerjaan yang dihasilkan, dan kerja jadwal.

c. Modeling

Proses ini digunakan untuk menciptakan sebuah sketsa untuk dapat memahami gambaran apa yang akan terlihat, bagaimana penyusunnya, dan banyak karakteristik lainnya. Jika perlu dengan menyempurnakan sketsa menjadi lebih besar dan lebih rinci dalam upaya untuk memahami masalah dan bagaimana mengatasinya. Hal ini dilakukan dengan menciptakan model untuk lebih memahami kebutuhan perangkat lunak dan desain yang akan mencapai persyaratan.

d. Construction

Kode ini dikombinasikan aktivasi generasi (baik secara manual atau otomatis) dan pengujian yang diperlukan untuk mengungkap kesalahan dalam kode.

Perangkat lunak (sebagai badan yang lengkap atau sebagian) yang dikirimkan ke pelanggan yang mengevaluasi disampaikan produk dan memberikan umpan balik berdasarkan evaluasi.

Gambar 1 Waterfall Model

1.6 Sistematika Penulisan

Sistematika penulisan penelitian ini disusun untuk memberikan gambaran umum tentang penelitian yang dijalankan. Sistematika penulisan Tugas Akhir ini adalah sebagai berikut :

BAB I PENDAHULUAN

Menguraikan latar belakang masalah, identifikasi masalah, batasan masalah, maksud dan tujuan, metodologi penelitian dan sistematika penulisan.

BAB II TINJAUAN PUSTAKA

Bab ini menguraikan konsep dasar, basis data, diagram kontek, diagram flow data, entri relationship diagram dan perangkat lunak pendukung yang berkaitan dengan penelitian yang akan dilakukan.

BAB III ANALISIS DAN PERANCANGAN SISTEM

Bab ini mengemukakan tentang langkah-langkah dasar pemecahan masalah berdasarkan analisa yang terdiri dari analisa masalah, analisa sistem yang sedang berjalan, analisa sistem yang akan dibuat dan juga menerangkan perancangan sistem yang akan dibuat, perancangan struktural, perancangan data dan perancangan antar muka (interface).

BAB IV IMPLEMENTASI DAN PENGUJIAN

Bab ini berisi penjelasan mengenai program yang telah dibuat berdasarkan desain sistem dan untuk mencoba program apakah telah sesuai dengan rancangan dan desain implementasi yang dibuat, juga untuk mencari kesalahan-kesalahan program yang mungkin terjadi untuk selanjutnya dapat dilakukan penyempurnaan implementasi dan pengujian program aplikasi.

BAB V KESIMPULAN DAN SARAN

Berisi kesimpulan dari hasil yang didapat dari penelitian dan saran-saran yang berguna untuk pengembangan sistem yang lebih baik dan bermanfaat.

1.2.3.Kasus dan hasil pengujian

Berdasarkan rencana pengujian, maka dapat dilakukan pengujian alpha dengan blackbox pada simulasi pencarian jalur terpendek menggunakan algoritma WHCA* dengan banyak agen yang dijelaskan pada tabel 4.4.

Tabel 4.4. Kasus dan hasil pengujian (data normal) Kasus dan hasil pengujian (data normal)

Aksi Yang

diharapkan

Pengamatan Kesimpulan

Memasukan titik awal

Menampilkan titik awal pada map Map menampilkan titik awal Diterima Memasukan titik tujuan Menampilkan titik tujuan pada map Map menampilkan titik tujuan Diterima Memasukan data halangan Menampilkan penghalang tembok pada map Map menampilkan penghalang Diterima Menekan tombol step Menampilkan rute reservasi pertama setiap unit pada map

Map menampilkan rute reservasi pertama Diterima Menekan tombol Animate Menampilkan setiap unit bergerak dari titik awal menuju titik akhir Sistem melakukan animasi perjalanan dari titik awal hingga titik tujuan

Diterima

Menekan tombol Stop

Menampilkan setiap unit pada posisi terakhir

Map

menampilkan setiap unit pada posisi terakhir Diterima Menekan tombol reset Menampilkan map dengan tanpa halangan dan unit Map menghapus data halangan dan unit Diterima Memasukan data nilai baris Contoh: 13 Dapat terisi number untuk masukan data nilai baris

Jumlah baris pada map sesuai dengan yang diinputkan

52

Tabel 4.5. Kasus dan hasil uji (data normal) Lanjutan

Masukan Yang

diharapkan

Pengamatan Kesimpulan

Memasukan data nilai kolom. Contoh: 10

Dapat terisi number untuk masukan data nilai kolom

Jumlah kolom pada map sesuai dengan yang diinputkan Diterima Klik tombol Grid Baru Menampilkan grid yang sesuai dengan masukan nilai baris dan nilai kolom Menampilkan map dengan jumlah baris dan kolom sesuai inputan Diterima

Tabel 4.6. Kasus dan hasil uji (data tidak normal)

Masukan Yang diharapkan Pengamatan Kesimpulan

Memasukan data titik awal pada posisi halangan

Muncul pesan konfirmasi bahwa titik awal tidak dapat diinput Hasil sesuai dengan yang diharapkan Diterima Memasukan data titik tujuan pada posisi halangan Muncul pesan konfirmasi bahwa titik tujuan tidak dapat diinput Hasil sesuai dengan yang diharapkan Diterima Memasukan data nilai kolom atau nilai baris melebihi batas grid Muncul pesan konfirmasi bahwa data melebihi batas grid Hasil sesuai dengan yang diharapkan Diterima Memasukan titik awal dan titik tujuan pada posisi yang sama Muncul pesan bahwa titik tujuan harus berbeda dengan titik awal Hasil sesuai dengan yang diharapkan Diterima Memasukan titik awal pada titik awal unit lain pada waktu yang sama Muncul pesan bahwa titik awal sudah digunakan oleh unit lain Hasil sesuai dengan yang diharapkan Diterima Memasukan titik tujuan pada titik tujuan unit lain pada waktu yang sama Muncul pesan bahwa titik tujuan sudah digunakan oleh unit lain Hasil sesuai dengan yang diharapkan Diterima

1.2.4.Pengujian Performansi

Performasi yang akan diuji pada aplikasi yang telah dibangun yaitu waktu tempuh dari posisi awal hingga posisi akhir setiap unit dan jumlah simpul yang diperiksa pada setiap siklus.

Performansi yang akan diuji pada aplikasi yang telah dibangun yaitu simpul yang diperiksa dan waktu yang ditempuh yang dihasilkan dengan Implementasi ordo minimal 5 x 5 tanpa penghalang dengan jumlah agen dari 2 hingga 8.

Gambar 4.3. Hasil pengujian ekspansi node

Hasil pengujian ekspansi node pada ordo 5x5, 10x10 dan 15x15 tanpa penghalang dengan jumlah agen dari 2 – 8 dapat dilihat pada tabel 4.7.

Tabel 4.7. Tabel hasil pengujian ekspansi node

Ordo \ jumlah unit 2 4 6 8

5X5 96 ms 357 ms 771 ms 892ms

10X10 309 ms 870 ms 1074 ms 1798 ms

15X15 622 ms 1154 ms 1793 ms 2486 ms

96

357

771 892

309

870

1074

1798

622

1154

1793

2486

0 500 1000 1500 2000 2500 3000

2 4 6 8

JUMLAH AGEN

Expansi node

54

Gambar 4.4. Hasil pengujian waktu eksekusi

Hasil pengujian waktu eksekusi pada ordo 5x5, 10x10 dan 15x15 tanpa penghalang dengan jumlah agen dari 2 – 8 dapat dilihat pada tabel 4.8.

Tabel 4.8. Tabel hasil pengujian hasil waktu eksekusi Ordo \ jumlah

unit

2 4 6 8

5X5 _{4.331 ms 8.811 ms 15.069 ms 55.467 ms} 10X10 _{38.686 ms 60.166 ms 90.995 ms 107.464 ms} 15X15 _{60.25 ms 93.122 ms 141.772 ms 166.999 ms}

1.2.5.Kesimpulan Pengujian Blackbox

Hasil pengujian dari pengujian blackboxyang telah dilakukan, menunjukkan bahwa aplikasi yang dibangun sudah memenuhi persyaratan fungsional, akan tetapi pada prosesnya masih memungkinkan untuk terjadinya kesalahan, namun frekuensi kesalahan masih relatif kecil. Secara fungsional sistem yang telah dibangun sudah dapat menghasilkan keluaran yang diharapkan. Jalan yang dihasilkan merupakan jalan terpendek karena simpul yang diperiksa relatif banyak dan memerlukan waktu pencarian yang relatif lama pula. Semakin banyak agen maka semakin banyak simpul yang diperiksa

4.331 8.811 15.069

55.467 38.686

60.166

90.995 107.464 60.25

93.122

141.772

166.999

0 50 100 150 200

2 4 6 8

JUMLAH AGEN

Waktu eksekusi

56

Pada bagian terakhir ini akan dikemukakan kesimpulan dari penelitian yang bersifat membangun.

5.1. Kesimpulan

Dari analisis algoritma dan hasil pengujian yang dilakukan, maka dapat ditarik kesimpulan bahwa semakin banyaknya agen dan jumlah grid maka proses pencarian jalur akan semakin lama dan jumlah ekspansi node semakin banyak.

5.2. Saran

Simulasi ini masih dapat dikembangkan lebih lanjut dengan perkembangan spesifikasi kebutuhan pengguna sistem yang harus dipenuhi dalam mencapai tahap yang lebih tinggi. Pada implementasi pencarian jalur terpendek menggunakan algoritma WHCA* ini nilai depth pada pencarian diambil secara tetap, sehingga adanya kemungkinan kesalahan dan kurang optimal pada saat pencarian jalur jika nilai depth tidak sesuai dengan jumlah grid dan jumlah unit. Oleh karena itu saran dari penulis adalah perlunya riset lebih lanjut tentang nilai depth pada pencarian WHCA* sehingga dapat mengurangi kesalahan pada saat pencarian dan lebih optimal pada saat pencarian jalur terpendek.

56 DAFTAR PUSTAKA

[1] D. Silver, "Cooperative Pathfinding," Department of Computing Science, Edmonton, Canada, 2005 .

[2] V. I. H. and D. A. , "Algoritma A* (A Star) Sebagai Salah Satu Contoh Metode Pemograman Branch and Bound".

[3] Stanford University, "From Amit’s Thoughts on Pathfinding," Stanford University, [Online]. Available:

http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#a-stars-use-of-the-heuristic. [Accessed 11 May 2015].

[4] Y. Li, W. Zhao, Z. Zhou and C. Chen, "Hierarchical and Dynamic Pathfinding Algorithms in Game Maps," International Journal of Advancements in Computing Technology, vol. 5, no. 11.10, p. 89, 2013. [5] A. Botea, M. Muller and J. Schaeffer, "Near Optimal Hierarchical

Path-Finding," Game Development, vol. 1, no. 1, pp. 8-12, 2004.

[6] J. E. Bentley, "Software Testing Fundamentals—Concepts, Roles, and Terminology," SUGI 30 Proceedings, vol. 1, p. 1, 2005.

[7] R. S. Pressman, Software Engineering: A Practitioner’s Approach, Fifth Ed. New York, McGraw-Hill Book Company, 2001.