Desain HASIL DAN PEMBAHASAN 4.1.

server. Nilai data dan model serta hasil manipulasinya akan dikirimkan ke agen DM

4.3 Desain

Klarifikasi permasalahan telah dilakukan dalam tahapan analisis. Dalam tahapan analisis ini tidak ditentukan spesifikasi solusi. Spesifikasi solusi dilakukan dalam tahapan desain. Dalam prosesnya, dimungkinkan untuk kembali ke tahapan analisis setelah berada dalam tahapan desain. Dalam tahapan desain, fokus langsung ditujukan menjadi sistem berplatform JADE. Penentuan platform yang akan dibangun perlu ditetapkan pada tahapan desain dikarenakan tahapan analisis yang telah dilakukan dapat saja tidak sesuai apabila diterapkan ke dalam platform pembangunan sistem multiagen. Dalam pengembangan model SPK multiagen, tahapan desain akan memfokuskan pada abstraksi untuk aspek kelayakan sumberdaya dan kelayakan pasar. Tahapan desain terdiri atas tahapan sebagai berikut : 1. Pemisahan penggabunganpenamaan agen Tahapan pertama dalam desain sistem multiagen adalah pemisahanpenggabungan agen. Pemisahanpenggabungan agen dilakukan dengan melakukan evaluasi kembali diagram agen yang telah dihasilkan pada analisis sistem. Tahapan ini merupakan salah satu tahapan yang penting karena dapat meningkatkan seluruh kinerja dan efisiensi sistem. Beberapa aturan diterapkan untuk melakukan tahapan ini Nikraz, 2006. Dalam SPK investasi multiagen, terdapat aturan yang berlaku sebagai berikut : a. Tidak adanya duplikasi data a b Gambar 13 Diagram Agen Deployment Pengaksesan User DM Provider Server Agen Decision Maker Agen Manajemen Agen Penyedia data dan model Agen fasilitator direktori Duplikasi data berarti adanya dua atau lebih agen yang berbagi sebagian besar informasi untuk melakukan tugasnya. Dalam SPK investasi hanya terdapat 1 satu agen yang menggunakan informasi dari agen penyedia data dan model. b. Tidak ada agen yang berbagi resources yang sama. Dalam SPK investasi terdapat 1satu agen yang mengakses resources, yaitu agen penyedia data dan model. c. Tiap agen disituasikan dalam mesin tunggal. Dalam SPK investasi multiagen tiap agennya berada dalam mesin tunggal. Berdasarkan aturan yang telah terpenuhi maka diagram agen yang telah dibentuk pada tahapan analisis tidak ada penambahanpenggabungan ataupun perubahan nama. Hal ini juga dikarenakan jumlah agen yang ada relatif sedikit. 2. Spesifikasi interaksi Dalam tahapan ini, semua responsibility dalam tiap agen yang dihubungkan dengan sebuah relasi acquaintance dengan agen lain dievaluasi untuk menghasilkan tabel interaksi. Tiap baris dalam tabel akan merepresentasikan interaksi dan akan termasuk di dalamnya: a. Nama deskriptif sebuah interaksi b. Responsibility yang memulai interaksi. Komponen ini dapat digunakan untuk memeriksa konsistensi antar analisis dan desain c. Protokol interaksi Interaction Protocol IP yang sesuai untuk interaksi tersebut. Spesifikasi IP dapat dilihat dalam spesifikasi protokol interaksi FIPA www.fipa.org . d. Role yang diperankan oleh agen dalam IP. Role dapat disimbolkan sebagai I untuk inisiator, atau R untuk responder. Role lain memungkinkan untuk ditambahkan bila diperlukan. e. Tipe dan nama agen f. Kondisi pemicu, misalnya kapan interaksi ini terjadi. Dalam kasus SPK investasi, maka dapat ditentukan tabel interaksi untuk tiap agen Tabel 4. Tabel 4 Tabel interaksi agen decision maker Interaksi Resp. IP Role Agen Kondisi Melakukan permintaan terhadap data atau model atau penjelasan 6-8 FIPA Propose I Agen decision maker Salah satu user mengirimkan data yang diperlukan user lain Merespon request antar user DM 5 FIPA Propose R Agen decision maker Request data atau hasil komputasi direspon Mengambil data model 9 FIPA Request R Agen penyedia data dan model Setiap query diterima dan database ditelusuri Mengambil penjelasan dari mesin inferensi 10 FIPA Request R Agen manajemen Penelusuran skenario untuk diberikan inferensi rule. Mendapatkan service pada agen penyedia data dan model 11 FIPA Request I Agen fasilitator direktori Agen DM mulai melakukan pengaturan skenario Berdasarkan tabel tersebut, maka dapat dijelaskan hal-hal sebagai berikut : Pada agen DM dan berdasarkan Gambar 12, terdapat interaksi untuk 4 agen, yaitu, interaksi antar user dalam agen DM, interaksi antara agen DM dan agen penyedia data model dan interaksi antara agen DM, agen manajemen serta agen fasilitator direktori. Dalam model roleresponsibility, interaksi ini merupakan salah satu atribut dalam responsibilities, yaitu protokol. Interaksi tersebut dijabarkan dalam kolom interaksi dalam Tabel 4. Kolom IP Interaction Protocol menyatakan protokol yang digunakan dalam interaksi tersebut. FIPA mengeluarkan standardisasi protokol IP. Pada setiap interaksi ditentukan protokol yang sesuai, apabila protokol tidak terdapat dalam standardisasi FIPA, maka dapat digunakan protokol ad-hoc yang mengikuti notasi dalam Agent Unified Modelling Language AUML. Gambar 14 dan Gambar 15 mendeskripsikan protokol interaksi yang digambarkan dalam notasi AUML. Dalam Gambar 14 terlihat terjadi dua interaksi antar inisiator dan partisipan. Dalam kasus SPK multiagen, interaksi terjadi antar user dalam agen DM. Salah satu user DM yaitu bidang sumberdaya berlaku sebagai inisiator dan user DM lain yaitu bidang pasar berlaku sebagai partisipan. Inisiator mengirim sebuah pesan kepada partisipan dan partisipan akan melakukan aksi tertentu bila setuju. Pesan yang dikirimkan adalah parameter kebutuhan CPO sebagai bahan baku. Parameter ini dibutuhkan oleh partisipan untuk menentukan jumlah CPO nasional yang diperlukan untuk memenuhi pasar biodisel. Komunikasi yang dilakukan oleh inisiator dan partisipan menggunakan communicative act dalam FIPA yaitu accept-proposal atau reject-proposal. Accept proposal diartikan sebagai aksi yang diminta oleh inisitor disetujui oleh partisipan. Persetujuan dapat dikeluarkan berdasarkan status partisipan dan data. User DM yaitu bidang sumberdaya dapat mengirimkan request untuk permintaan hasil komputasi pada user DM bidang pasar. User DM bidang pasar akan merespon permintaan user DM bidang sumberdaya. Secara umum, iteraksi antar user agen DM dilakukan ketika dibutuhkannya parameter yang terdapat di salah satu user agen tersebut.. Interaksi dalam agen DM juga terjadi antara agen DM dan agen penyedia data dan model. Interaksi menggunakan protokol IP FIPA Request. Pada protokol Gambar 14 Protokol FIPA Propose FIPA Propose Interaksi Agen DM – Agen Penyedia data dan Model ini sebuah agen dimungkinkan untuk melakukan permintaan ke agen lain untuk melakukan sesuatu. Partisipan akan memproses permintaan dan membuat keputusan. Apabila keputusan yang dibuat adalah menolak, maka variabel “menolak” menjadi benar dan partisipan mengomunikasikan coomunicative act “menolak”. Hal yang sama juga dilakukan apabila keputusan partisipan adalah setuju. Gambar 15 menunjukkan interaksi dalam notasi AUML. Tabel interaksi juga dispesifikasikan untuk agen penyedia data dan model dan agen manajemen seperti yang terlihat dalam Tabel 5 dan Tabel 6. Tabel 5 Interaksi dalam agen penyedia data dan model Interaksi Resp. IP Role Agen Kondisi Merespon permintaan dari agen DM 1 FIPA Request R Agen decision maker Agen penyedia data menerima permintaan dari user agen DM Mengirimkan data permintaan user agen DM 2 FIPA Request I Agen decision maker Permintaan data atau model dikirimkan ke user agen DM Melakukan registrasi pada fasilitator direktori 3 FIPA-Contract Net I Agen Fasilitator direktori Layanan berupa penyediaan data dan model didaftarkan ke agen direktori fasilitator Gambar 15 Protokol FIPA Request FIPA Request Interaksi Agen DM Pasar – Agen Penyedia Data dan Model Tabel 6 Tabel interaksi dalam agen manajemen Interaksi Resp. IP Role Agen Kondisi Merespon permintaan dari agen DM 1 FIPA Request R Agen decision maker Agen manajemen menerima permintaan dari user agen DM Mengambil data dan model 2 FIPA Request I Agen decision maker Permintaan penjelasan hasil inferensi dikirimkan ke user agen DM Melakukan registrasi pada fasilitator direktori 3 FIPA Contract- Net I Agen fasilitator direktori Permintaan data atau model untuk diolah dalam proses inferensi Pada Tabel 5 dan 6 protokol interaksi yang digunakan untuk relasi acquaintance adalah FIPA Request dan FIPA Contract-Net. Pada protokol FIPA Request, interaksi terjadi antara agen penyedia data dan model sebagai inisiator dan agen DM sebagai partisipan Gambar 15. Komunikasi antara inisiator dan partisipan dilakukan dalam hal pengambilan salah satu parameter penentu nilai sumberdaya atau pasar dalam sistem aplikasi. Permintaan parameter data oleh inisiator akan ditanggapi oleh partisipan melalui persetujuan. Setelah persetujuan dikirimkan, partisipan akan meneruskan dengan pengiriman data. Terdapat 3 kemungkinan kondisi yang terjadi, yaitu pengiriman gagal dilakukan, notifikasi berhasil, akan tetapi data belum dikirimkan dan data diterima oleh inisiator. Simbol diamond merupakan notasi AUML sebagai operator yang menunjukkan alternatif kondisi yang terjadi. Protokol interaksi FIPA Contract-Net digunakan oleh Agen Fasilitator Direktori yang berelasi acquaintance dengan Agen DM. Diagram sequence untuk protokol ini disajikan pada Gambar 16. Seperti yang dikemukakan oleh Nikraz 2006 komunikasi yang dilakukan oleh agen ke agen fasilitator direktori untuk registrasi maupun pencarian layanan dilakukan dengan protokol interaksi yaitu FIPA Contract-Net. Dalam protokol ini kedua agen melakukan negoisasi untuk melakukan aksi tertentu. Dalam Gambar 15 dapat dijelaskan bahwa salah satu user agen DM mengajukan permintaan untuk registrasi ataupun pencarian layanan-layanan yang terdaftar dalam agen FD. Agen FD akan merespon dengan mengirimkan notifikasi penolakan atau persetujuan. Persetujuan akan registrasi dan pencarian layanan berisi layanan-layanan alterntif yang ditemukan berdasarkan pencarian oleh agen DM. Layanan yang disediakan agen FD dapat juga ditolak atau diterima oleh agen DM. Persetujuan agen DM akan membuat agen FD melakukan 3 tiga hal yaitu, gagal dilakukannya registrasi ataupun pencarian, notifikasi aksi bisa dilakukan dan proses registrasi dan layanan dilakukan. 3. Definisi protokol ad-hoc Semua interaksi protokol yang didefinisikan untuk melingkupi interaksi antar agen telah terakomodasi dalam FIPA protokol, untuk itu dalam kasus SPK investasi multiagen tidak diperlukan lagi definisi protokol ad-hoc. Oleh karena itu proses desain sistem dapat dilanjutkan ke tahapan berikutnya. 4. Mendefinisikan Message Template Tahapan selanjutnya dalam pengembangan sistem adalah mengimplementasikan semua role interaksi yang telah didefinisikan ke dalam behaviour JADE. Dalam tahapan ini, objek MessageTemplate yang sesuai dispesifikasikan untuk digunakan dalam behaviour untuk menerima message. Dalam tahapan ini, terjadi proses updating tabel interaksi. Kolom terakhir pada tiap baris dalam tabel interaksi ditambahkan template yang sesuai. Terdapat aturan untuk melakukan proses updating. Aturan tersebut adalah sebagai berikut : a. Inisiator diimplementasikan dengan menggunakan MessageTemplate berdasarkan conversationID dalam kelas behaviour . Conversation ID adalah pengenal dalam inisiator untuk menyatakan role agen yang bersangkutan dalam interaksinya dengan agen lain. b. Responder atau partisipan diimplementasikan dengan MessageTemplate berdasarkan performatif dan ontologi dalam kelas always-active behaviour. Dalam komunikasi antar agen, format yang digunakan adalah berdasarkan agent communication language ACL. ACL menspesifikasi hal-hal seperti : performative yang berisi tipe dan arti tiap-tiap pesan, agen pengirim dan penerima, protokol, ontologi dan reply-with Kawamura, 1999. Berdasarkan aturan tersebut, maka message template yang ditentukan untuk tiap role dapat disajikan pada Tabel 7,8 dan 9 Tabel 7,8 dan 9 dapat diinterpretasikan sebagai berikut : - Interaksi yang dilakukan oleh user agen DM memiliki template conv-id berdasarkan role sebagai inisiator. ID yang dihasilkan adalah ID yang unik sehingga tidak terjadi konflik dengan agen lain. FIPA Contract –Net Interaksi Agen DM dan Agen Manajemen dan Agen Penyedia data dan Model Gambar 16 Diagram Sequence untuk protokol FIPA Contract Net - Interaksi yang dilakukan oleh agen dengan role responder atau partisipan dilakukan dengan merespon berdasarkan performatif dari ACL message yang dikirimkan kembali. Dalam SPK investasi biodisel multiagen interaksi antara agen DM dan agen penyedia data dan model dilakukan dengan merespon permintaan agen DM sesuai dengan performatif request. Oleh karena itu template yang digunakan adalah Perf=request. Template yang ditampilkan pada Tabel 7 merupakan template umum yang diambil dari template secara lengkap yang terdapat pada paket jade.lang.acl JADE versi 3.6 API untuk kelas MessageTemplate. Berdasarkan implementasi behaviour dan MessageTemplate, secara umum dapat dihasilkan pola template dinamik seperti yang terlihat pada Gambar 17 Nikraz, 2006. Tabel 7 Message template untuk agen DM Interaksi Resp. IP Role Agen Kondisi Template Merespon request antar user DM 5 FIPA Propose R Agen decision maker Request data atau hasil komputasi direspon Perf=pro pose Melakukan permintaan terhadap data atau model atau penjelasan 6-8 FIPA Propose I Agen decision maker Salah satu user mengirimkan data yang diperlukan user lain Conv-Id Mengambil data model 9 FIPA request I Agen penyedia data dan model Setiap query diterima dan database di telusuri Conv-Id Interaksi Resp. IP Role Agen Kondisi Template Mengambil penjelasan dari mesin inferensi 10 FIPA Request I Agen manajemen Penelusuran skenario untuk diberikan inferensi rule. Conv-Id Mendapatkan service pada agen penyedia data dan model 11 FIPA Request I Agen fasilitator direktori Agen DM mulai melakukan pengaturan skenario Conv-Id Tabel 8 Message template untuk agen penyedia data dan model Interaksi Resp. IP Role Agen Kondisi Template Merespon permintaan dari agen DM 1 FIPA Request R Agen decision maker Agen penyedia data menerima permintaan dari user agen DM Perf=request Interaksi Resp. IP Role Agen Kondisi Template Mengirimkan data permintaan user agen DM 2 FIPA Request I Agen decision maker Permintaan data atau model dikirimkan ke user agen DM Conv-Id Melakukan register pada fasilitator direktori 3 FIPA- Contract Net I Agen fasilitator direktori Service berupa penyediaan data dan model didaftarkan ke agen fasilitator direktori Conv-Id Tabel 9 Message template untuk agen manajemen Interaksi Resp. IP Role Agen Kondisi Template Merespon permintaan dari agen DM 1 FIPA Request R Agen decision maker Agen manajemen menerima permintaan dari user agen DM Perf=request Mengambil data dan model 2 FIPA Request I Agen decision maker Permintaan penjelasan hasil inferensi dikirimkan ke user agen DM Conv-Id Melakukan registrasi pada fasilitator direktori 3 FIPA Request I Agen penyedia data dan model Permintaan data atau model untuk diolah dalam proses inferensi Conv-d Pola template dinamik dihasilkan berdasarkan objek jade.lang.acl.ConversationList dalam agen. Semua behaviour inisiator melakukan registrasi pada objek ConversatioList melalui metode onStart dan deregister melalui metode onEnd. Oleh karena itu, objek conversationlist dapat mendata semua interaksi yang dimulai oleh agen sebagai inisiator dan mampu menyediakan messagetemplate yang sesuai bagi pesan-pesan yang bukan dimiliki oleh interaksi ini. Behaviour responder atau partisipan dengan template yang konflik kemudian dapat menggunakan template yang disediakan oleh ConversationList untuk mencegah konflik dengan semua inisiator. 5. Membentuk Diagram Kelas Dalam sistem berbasis agen, agen dapat mencari atau mendaftarkan service ke dalam katalog yellow page Caire, 2004. Katalog ini diatur di dalam fasilitas direktori JADE. Untuk penggambaran service –service yang dapat didaftarkan dan dicari agen dapat dilakukan melalui diagram kelas pada Gambar 18. Notasi diagram kelas mengikuti notasi yang dikemukakan oleh Nikraz 2006. Melalui diagram kelas dapat dijelaskan bahwa dalam tiap agen dihasilkan service yang menjadi kelas dengan beberapa atribut seperti tipe, ontologi, protokol. Tipe adalah jenis informasi yang dicari atau disediakan oleh agen. Ontologi merupakan deskripsi formal yang menggambarkan data dan informasi. Spesifikasi detil ontologi untuk SPK investasi multiagen akan ditentukan dalam tahapan berikutnya. 6. Mendefinisikan Interaksi antara Agen dan Resources Dalam sebuah sistem, kerapkali terdapat interaksi antara satu agen atau lebih dengan sumberdaya eksternal, misalnya database, file, ataupun software aplikasi lain. Dalam beberapa kasus, interaksi membutuhkan hardware untuk pengontrolan. Dalam kasus SPK investasi multiagen, seperti yang telah dihasilkan dalam diagram agen, maka terdapat interaksi antara agen dan sumberdaya eksternal lain, yaitu file dan software aplikasi lain. Sumberdaya juga dapat dibagi menjadi dua kategori, yaitu sumberdaya aktif dan sumberdaya pasif. Sumberdaya aktif adalah sumberdaya yang dapat mengubah statusnya sendiri dan tidak tergantung pada agen yang mengontrolnya. Gambar 17 Dynamic Template Pattern Dalam sumberdaya aktif, terdapat beberapa kemungkinan interface antarmuka untuk pengontrolan perubahan yang terjadi pada sumberdaya, di antaranya : - Penggunaan antarmuka yang disebut listener-based interface, yaitu antarmuka yang digunakan untuk mengontrol agen sehingga dapat dengan cepat mendeteksi perubahan dalam sumberdaya, - Penggunaan antarmuka yang menggunakan metode blocking sampai perubahan dideteksi. - Melakukan polling periodik terhadap sumberdaya untuk mendeteksi perubahan yang terjadi. Untuk kepentingan implementasi, maka digunakan satu pendekatan untuk menyamakan ketiga kemungkinan pengontrolan perubahan agen seperti yang dijelaskan sebelumnya. Aturan yang perlu diterapkan untuk melakukan pendekatan tersebut adalah sebagai berikut : Gambar 18 Diagram kelas service yang disediakan agen -Tipe = : unspecified = Model kelayakan sumberdaya -Ontologi = : unspecified = Model kelayakan -Protokol = : unspecified = FIPA-request Mencari model ketersediaan sumberdaya Agen DM Menyediakan -Tipe = : unspecified = Model kelayakan sumberdaya APDM_SD:Menyediakan model ketersediaan sumberdaya Agen Penyedia data dan Model Mencari Agen DM Mencari -Tipe = : unspecified = Parameter penentu -Ontologi = : unspecified = Parameter -Protokol = : unspecified = FIPA-request Mencari parameter yang mempengaruhi ketersediaan sumberdaya Menyediakan -Tipe = : unspecified = Parameter penentu Menyediakan parameter penentu ketersediaan sumberdaya Agen Manajemen - Jika tidak terdapat listener-based interface, maka dapat digunakan Java thread atau thread yang dapat mendeteksi perubahan dalam resources dan dapat berlaku sebagai listener notifer. Listener notifier bertindak sebagai pendeteksi untuk memberikan notifikasi bila ada perubahan. - Menyediakan notifier dengan listener sehingga tiap panggilan dari notifier menghasilkan penambahan behaviour yang sesuai ke agen berdasarkan behaviour listener. - Menggunakan objek jade.util.Event dan metode waituntilProcessed dan notifyProcessed untuk sinkronisasi listener dan behaviournya ketika hasil harus dilewatkan kembali ke notifier sebagai hasil balikan metode interface listener. Dalam SPK investasi multiagen, aksi yang dapat dilakukan secara paralel terkait dengan interaksi yang terjadi antara agen dan resources yaitu agen DM dan agen penyedia data dan model. File dan software aplikasi sebagai agen penyedia data dan model adalah sumberdaya aktif yang dapat mengubah statusnya sendiri. Proses paralel yang dimungkinkan terjadi dalam interaksi kedua elemen ini adalah pada saat agen DM membutuhkan data yang terkait dengan kelayakan sumberdaya dengan parameter inputan berupa produktivitas tiap perkebunan. Dalam hal ini sumberdaya agen penyedia data dan model secara konkuren menerima inputan untuk memodifikasi data dan model dalam aplikasinya. Dalam interaksi seperti ini, sinkronisasi dilakukan dengan menerapkan metode waituuntilProcessed dan notifyProcessed. Metode waituntilProcessed akan dilakukan oleh agen penyedia data dan model bagi setiap agen yang akan melakukan pengaksesan informasi di dalamnya. Metode ini menerapkan blocking sampai metode notifyProcessed dipanggil oleh agen penyedia data dan model. Kedua metode ini terdapat di dalam kelas jade.util.Event. 7. Mendefinisikan interaksi antara user dan agen Interaksi antara user dan agen kerap kali dilakukan dalam SPK multiagen. Interaksi dilakukan melalui Graphical User Interface GUI. Terdapat dua macam GUI, yaitu GUI local dan GUI untuk web. Untuk SPK multiagen investasi, GUI yang digunakan dalah tipe lokal GUI dan dapat diimplementasikan dengan Swing ataupun Abstract Windowing Toolkit awt. Dalam lokal GUI beberapa aspek yang perlu diperhatikan adalah agen dan GUI bekerja pada data yang sama tetapi dengan harus dapat mengorganisasikan data ini dalam cara yang berbeda. Hal ini dapat menyebabkan duplikasi data dan berujung pada inkonsistensi data. Untuk mengatasi hal ini, maka dalam implementasi GUI dengan Swing dapat digunakan Model-View-Controller Sun Microsystem, 2002. Dalam SPK investasi multiagen, interaksi antara user dan agen dilakukan dengan menentukan elemen inputan bagi user agen DM untuk dikirim ke aplikasi penyedia data dan model. Selain hasil kelayakan sebagai output, user juga dapat memperoleh hasil inferensi rule apabila terdapat keterkaitan antar parameter untuk kemudian menjadi elemen penjelasan atau penalaran. Beberapa parameter yang dapat diinputkan untuk menjadi parameter penentu kelayakan dari aspek ketersediaan sumberdaya dan pasar adalah Lampiran 1: - Produktivitas 3 perkebunan, - Persentase CPO yang diekspor - Kebutuhan perkapita dalam pemakaian CPO untuk minyak goreng - Persentase CPO dipakai untuk minyak goreng, - Persentase kenaikan CPO untuk bahan Oleokimia. - Persentase biodisel menggantikan solar. - Konsumsi solar Dalam hal ini, user akan menerima daftar parameter yang ditampilkan untuk dapat diinputkan oleh user. Daftar parameter ini akan diolah oleh aplikasi penyedia data dan model untuk diperoleh hasil kelayakannya. Peran agen manajemen akan terlihat ketika user melakukan proses penalaran dari keputusan yang diambil oleh aplikasi penyedia data dan model. 8. Merancang behaviour internal agen Dalam sistem yang dikembangkan dengan pendekatan agen, pekerjaan sesungguhnya dalam agen didefinisikan dalam behaviour agen. Dalam tahapan ini, semua responsibilities yang telah ditentukan dalam tahapan analisis dievaluasi dan dilakukan pemetaan tabel responsibility menjadi behaviour agen. Untuk pemetaan tersebut terdapat aturan yang dapat diterapkan dalam menghasilkan behaviour yang berkaitan. Aturan tersebut adalah : untuk sebuah responsibility dalam tabel interaksi yang dihasikan dalam tahapan desain maka dapat ditentukan kelas JADE yang diperlukan untuk mengimplementasikan IP dan role interaksi tersebut. Selain penentuan kelas JADEnya, perlu disediakan pula ekstensi yang sesuai. Dalam kasus SPK investasi multiagen, maka terdapat beberapa responsibilities yang telah dapat ditentukan behaviour JADE yang sesuai, di antaranya : 1. Semua responsibilities dengan IP FIPA-propose, maka dapat digunakan sub kelas dari kelas jade.proto.ProposeInitiator dan kelas jade.proto.ProposeResponder, tergantung apakah role yang berlaku sebagai inisiator atau responder. 2. Untuk IP FIPA-request dapat digunakan sub kelas dari kelas jade.proto.ArchieveInisiator dan jade.proto.ArchieveResponder. Dalam menentukan behaviour internal tiap agen, JADE juga menyediakan sebuah sub kelas untuk pengeksekusian behaviour tersebut. Sub kelas tersebut adalah : public void action untuk menyatakan behaviour yang dilakukan dan public boolean done: yang menyatakan apakah behaviour telah dilakukan. Tiap agen dapat mengeksekusi behaviour-nya secara paralel, akan tetapi penjadwalan pelaksanaan behaviour adalah bukan bersifat preemptive akan tetapi kooperatif, dan semuanya diimplementasikan dalan Java thread tunggal. Dalam SPK investasi biodisel multiagen, behaviour internal tiap agen dapat didefinisikan menggunakan instance dari sub kelas behaviour dan memanggil metode addbehaviour dalam kelas agen. Behaviour internal dari agen DM melakukan tugas pengiriman parameter kelayakan sumberdaya dan pasar dengan melewatkan parameter tersebut sebagai argumen atau pengiriman pesan kepada agen penyedia data dan model. Agen penyedia data dan model akan terus menyediakan data dan model dasar yang dapat digunakan oleh agen lain, yaitu agen DM dan agen manajemen. Pengiriman parameter ke dan dari agen penyedia data dan model dan kegiatan modifikasi dapat dilakukan secara paralel. Walaupun proses dapat diakukan secara paralel, behaviour dilakukan dengan Java thread tunggal. Hal ini berarti terjadi perpindahan kontrol dari satu behaviour ke behaviour lain. Perpindahan behaviour dilakukan berdasarkan hasil balikan metode action. Dalam kaitannya dengan SPK investasi biodisel multiagen, agen DM dapat terus meminta hasil kelayakan sumberdaya dan pasar berdasarkan parameter inputan, akan tetapi agen penyedia data dan model dengan mekanisme pendeteksian perubahan, akan melakukan blocking terhadap agen DM untuk menerima data dikarenakan proses modifikasi tersebut. Berdasarkan hal tersebut, eksekusi behaviour internal dalam agen DM dapat digambarkan melalui bagan alir pada Gambar 19. Dalam Gambar 19 terjadi satu eksekusi behaviour internal agen DM dalam mendapatkan hasil kelayakan sumberdaya dan pasar. Dalam metode action, agen DM mengirimkan parameter inputan penentu kelayakan ke penyedia data dan model. Setelah metode done mengembalikan nilai benar, maka agen DM akan mendapatkan hasil kelayakan. Behaviour internal seperti ini dalam JADE dapat dikategorikan ke dalam tipe wakerbehaviour yaitu behaviour yang mengimplementasikan tugas tunggal dan berakhir dalam satuan waktu tertentu Fabio, 2008. Secara lengkap terdapat 4 empat tipe bahviour, yaitu : a. OneShotBehaviour Kelas ini mengimplementasikan sebuah tugas yang berjalan sekali dan berakhir dengan cepat. b. CyclicBehaviour Kelas ini mengimplementasikan sebuah tugas yang selalui aktif, dan melakukan operasi yang sama sesuai penjadwalan yang ditentukan. c. TickerBehaviour Kelas ini mengimplementasikan tugas yang secara periodik mengeksekusi operasi yang sama. d. WakerBehaviour Kelas ini mengimplementasikan sebuah tugas tunggal yang berjalan setelah satuan waktu tertentu dan kemudian berakhir. Berkaitan dengan responsibility yang kompleks, dapat dilakukan pemecahan responsibility tersebut menjadi sejumlah tugas yang lebih sederhana. Responsibility yang telah dipecah dapat dikombinasikan sehingga behaviour gabungan yang disediakan oleh JADE dapat diadopsi. Behaviour ini adalah: a. SequentialBehaviour Behaviour ini mengimplementasikan sebuah tugas gabungan yang menjadwalkan sub tugasnya secara sequential. b. FSMBehaviour Behaviour ini mengimplementasikan sebuah tugas gabungan yang menjadwalkan sub tugasnya sesuai dengan Finite State Machine Dalam kasus SPK investasi multiagen terdapat responsibilties kompleks yang kemudian dapat memunculkan subresponsibilities, yaitu user agen DM mengatur skenario kelayakan. Responsibility ini dapat diimplementasikan dengan behaviour dalam JADE. Tugas yang dilakukan dalam pengaturan skenario telah mengarah kepada spesifik implementasi. Oleh karena itu, perluasan langsung dari kelas yang ada dalam JADE tidak dapat dilakukan. Untuk itu, responsibility penentuan kelayakan sumberdaya dan pasar dapat digambarkan melalui state machine pada Gambar 20 . Notasi yang digunakan dalam Gambar 19 mengikuti notasi yang dikemukakan oleh Nikraz 2006 dalam pengembangan sistem multiagen dengan platform JADE. Dari gambar terlihat dalam sebuah responsibility yang tidak dapat ditentukan behaviournya dalam kelas JADE, maka dapat diturunkan sub responsibility-nya. Sub-responsibility ini juga akan dapat melakukan interaksi dengan agen lain, seperti contoh dalam state membaca data dan model kelayakan. Dalam state ini, user agen DM akan berinteraksi dengan agen penyedia data dan model untuk menampilkan daftar parameter yang akan diatur skenarionya untuk penentuan kelayakan sumberdaya dan pasar. Untuk interaksi dengan agen penyedia data dan model maka dapat digunakan kelas jade.proto.ProposeInitiator. Dari gambar terlihat dalam sebuah responsibility yang tidak dapat ditentukan behaviournya dalam kelas JADE, maka dapat diturunkan sub responsibility-nya. Sub-responsibility ini juga akan dapat melakukan interaksi dengan agen lain, seperti contoh dalam state membaca data dan model kelayakan. Dalam state ini, user agen DM akan berinteraksi dengan agen penyedia data dan model untuk menampilkan daftar parameter yang akan diatur skenarionya untuk penentuan kelayakan sumberdaya dan pasar. Untuk interaksi dengan agen Setup Agen masih aktif ? Ya Ambil behaviour berikutnya dari semua behaviour yang aktif b.action b.done? YA Behaviour dipindahkan dari pool behaviour aktif TIDAK TIDAK - Inisialisai agen - Penambahan behaviour awal - Menginput data parameter , di antaranya produktivitas, persentase ekspor CPO, kebutuhan minyak goreng, dll Hasil kelayakan diperoleh Takedown Operasi penyelasain behaviour Gambar 19 Bagan alir eksekusi behaviour internal agen penyedia data dan model maka dapat digunakan kelas jade.proto.ProposeInitiator. 9. Pendefinisian Ontologi Ontologi adalah sekumpulan konsep, predikat dan aksi agen sesuai dengan domain yang telah ditentukan pada tahapan awal. Dalam interaksi antar agen, maka terjadi pertukaran informasi antar agen tersebut. Informasi yang dipertukaran akan merujuk kepada entitas, abstraksi atau kongkret yang berada dalam lingkungan tempat agen tersebut berada. Entitas dapat berupa tipe data primitif seperti string atau bilangan atau dapat berupa struktur kompleks yang Gambar 20 Diagram state machine untuk responsibility mengatur skenario k l k Mengatur skenario kelayakan sumberdaya dan pasar Parameter kelayakan tersedia dalam daftar Memilih parameter Sukses Gunakan peringatan untuk memilih parameter Gagal Layar awal Menampilkan List parameter untuk kelayakan Parameter kelayakan tidak tersedia dalam daftar List ditampilkan dalam layar User memasukan dan menekan tombol proses User tidak memasukkan parameter Menyediakan pilihan untuk memasukkan parameter Tidak ada respon dari user Kembali ke layar awal Membaca data dan model kelayakan Tidak terdapat dalam daftar Sistem error didefinisikan oleh template tertentu dengan terdapat field berupa nama atau nilai lain. Entitas kompleks seperti inilah yang dapat disebut sebagai konsep. Entitas juga dapat merujuk sebuah relasi yang bernilai benar atau salah. Untuk entitas yang kompleks, relasi juga mempunyai struktur yang didefinisikan oleh template dengan terdapat field nama dan nilai lainnya. Relasi ini dapat disebut dengan predikat. Entitas yang kompleks juga direpresentasikan oleh deskripsi aksi yang dilakukan agen. Template aksi ini disebut sebagai agen actions. Untuk mengekspresikan ontologi dapat digunakan formalisme yang berbeda. Formalisme dapat digunakan dengan notasi UML. Aturan yang berkaitan untuk bentuk formal ontologi adalah sebagai berikut : - Tiap template ontologi diekspresikan sebagai sebuah kelas. - Stereotype digunakan untuk membedakan antara konsep, predikat dan aksi agen. - Template ontologi yang mempunyai tipe data primitif diekspresikan sebagai atribut dari kelas yang bersangkutan. - Template ontologi yang mempunyai tipenya sendiri diekspresikan sebagai sebuah role dari sebuah elemen yang memiliki field dengan konsep yang merepresentasikan tipe field tersebut. - Hasil dan efek yang diakibatkan dari eksekusi sebuah aksi didokumentasikan sebagai komentar yang dipasangkan ke dalam aksi agen. - Relasi pewarisan digunakan untuk mengindikasikan bahwa sebuah template ontologi diwariskan kepada template ontologi lain. Dalam pendefinisian ontologi perlu diperhatikan bahwa ontologi merupakan sebuah model yang menggambarkan domain aplikasi. Ontologi sebaiknya mempunyai struktur yang sederhana tetapi lengkap yang dapat digunakan agen dalam melakukan tugasnya. Untuk itu, perlu diperhatikan bahwa konsep dan predikat yang dimasukkan dalam ontologi adalah konsep dan predikat yang hanya dibutuhkan agen dalam berinteraksi. Dalam hal ini, berarti konsep dan predikat yang mempunyai instance yang harus dikodekan dalam ACL dan dipertukarkan antar dua atau lebih agen. Dalam kasus SPK multiagen, maka dapat ditentukan konsep, relasi dan aksi agen dalam Tabel 10. Tabel 10 Konsep, relasi dan aksi agen dalam SPK investasi biodisel multiagen KATEGORI ENTITI FIELD Konsep Parameter Nama String Tipe Number, String Model Nama String Hasil Balikan Number User DM Nama String Lokasi String Penjelasan Parameter String Relasi Diambil Apa Parameter Dimana Model dan Data Nilai jangka waktu Tahun Siapa User DM Aksi Agen Ambil Data Parameter Int, Float User DM String Penjelasan String Tahun String Kirim Inferensi Model String User DM String Penjelasan String Berdasarkan aturan yang telah ditetapkan untuk mengekspresikan ontologi dalam sebuah sistem multiagen, maka ontologi untuk SPK investasi multiagen adalah sebagai berikut : - Tiap template ontologi dinyatakan dalam kelas. Berdasarkan identifikasi, maka terdapat 5 kelas yang terdiri atas 3 tiga konsep, 1satu predikat atau relasi dan 1satu aksi agen. Stereotype digunakan untuk membedakan konsep, predikat dan aksi agen. Kelas diagram yang dapat dibentuk untuk SPK investasi multiagen adalah sebagai berikut Gambar 21: Berdasarkan Gambar 22, ontologi untuk SPK investasi multiagen adalah sebagai berikut : Gambar 21 Kelas diagram dalam template ontologi Gambar 22 Ontologi dalam SPK investasi multiagen -Nama : string -Tipe : long Parameter -Nama : char -Hasil : long Model -Bagian : char -Lokasi : char User DM -Tahun : int Diambil -Kategori : int Kirim Inferensi -Tahun : int Ambil Data +apa +siapa +apa Mengirimkan hasil inferensi untuk penjelasan kelayakan Mengembalikan nilai kelayakan Diagram kelas yang menggambarkan ontologi untuk SPK investasi biodisel kelapa sawit dapat diinisialisasi sesuai dengan kelayakan sumberdaya dan pasar. Diagram kelas yang berkaitan dengan elemen-elemen pada ontologi SPK investasi multiagen disajikan pada Gambar 23. Berdasarkan Gambar terdapat 3 tiga konsep yang digunakan dalam ontologi SPK investasi biodisel multiagen. Nilai untuk tiap-tiap konsep, predikat dan aksi agen dijabarkan pada Tabel 11. Tabel 11. Nilai slot elemen ontologi No KONSEP PREDIKAT AKSI AKSI AGEN 1 PARAMETER - Produktivitas 3 tiga perkebunan - Presentase CPO ekspor - Konsumsi minyak goreng kapita tahun - Pertumbuhan oleokimia - Konsumsi BBM solar - Persentase biodisel menggantikan solar DIAMBIL - Tahun KIRIM DATA DAN INFERENSI - Kategori 2 MODEL - Kelayakan sumberdaya - Kelayakan pasar AMBIL DATA DAN INFERENSI - Tahun 3 USER DM User kelayakan sumberdaya - User kelayakan pasar Gambar 23 Diagram kelas untuk ontologi SPK investasi multiagen 10. Pemilihan bahasa implementasi JADE menyediakan aplikasi untuk pengkodean yaitu bahasa SL dan bahasa LEAP. Bahasa SL merupakan bahasa yang mudah dibaca oleh manusia sedangkan bahasa LEAP adalah bahasa konten yang tidak dapat dibaca oleh manusia. Bahasa LEAP biasa digunakan untuk sistem dengan penggunaan piranti bergerak, misalnya telepon selular sedangkan SL adalah bahasa yang dapat digunakan untuk implementasi sistem yang akan diterapkan dengan kemampuan komputer yang tinggi. Dalam SPK investasi multiagen, bahasa SL lebih cocok untuk diterapkan dalam pengkodeannya. Selengkapnya, untuk implementasi dapat digunakan kelas Slcodec yang telah disediakan Fabio, 2008.

4.4. Deployment