IV. HASIL DAN PEMBAHASAN
4.1. Pengembangan Sistem
SPK investasi industri biodisel kelapa sawit yang dikembangkan oleh Mariana (2005) merupakan SPK investasi berbasis model untuk penentuan kelayakan industri biodisel dengan 5 (lima) aspek kelayakan yaitu : kelayakan sumberdaya, kelayakan pasar, kelayakan teknis produksi, kelayakan finansial dan kelayakan lingkungan.
Dalam SPK investasi yang telah dibangun, pengambil keputusan dapat mengatur skenario kelayakan dengan memasukkan parameter inputan. Hasil perhitungan kelayakan diperoleh berdasarkan model matematika dalam tiap sub model. Penilaian kelayakan ditentukan oleh pengambil keputusan berdasarkan nilai yang diperoleh. Bagan alir penentuan kelayakan dan model matematika terdapat dalam Lampiran 1. Kelima aspek kelayakan direpresentasikan dalam sub model yang diimplementasikan dengan bantuan aplikasi spreadsheet (Microsoft Excel) dan perangkat lunak I-think versi 6.0.
Aplikasi SPK yang dihasilkan mampu menyajikan sistem yang interaktif kepada pengguna. Pengguna dapat melihat semua aspek kelayakan sesuai dengan skenario yang dipilih. Pemodifikasian model dan data oleh pengembang tidak dilakukan secara interaktif, melainkan dilakukan langsung melalui aplikasi pembentuk SPK.
Kegiatan modifikasi model dan data merupakan hal yang menjadi fokus dikarenakan dalam pengembangannya akan terdapat perubahan model dan data dasar. Modifikasi yang dilakukan langsung melalui aplikasi pembentuk dapat mempengaruhi operasional sistem secara keseluruhan karena sistem dibangun dengan konsep sentralisasi dan compact.
Konsep desentralisasi dan modularity dapat dikembangkan dalam SPK investasi biodisel dikarenakan sub model pembentuk SPK dapat menjadi sub SPK untuk penilaian kelayakan berdasarkan perspektif kepentingan pengambil keputusan. Kedua konsep ini terdapat dalam sistem berbasis agen. Melalui pemodelan agen, model pembentuk SPK dijadikan komponen yang otonom
dengan masing-masing model secara terpisah mempunyai fungsi kontrol dan merupakan sub sistem yang proaktif apabila terjadi perubahan pada lingkungannya.
4.2. Pengembangan Model Sistem Penunjang Keputusan Multiagen
Pengembangan sistem berbasis agen mengikuti metodologi yang mulai dikembangkan tahun 2000. Beberapa metodologi telah disusun untuk membangun sebuah sistem multiagen, di antaranya Gaia (Wooldridge, 2000), Roadmap (Juan, 2002) dan terakhir adalah metodologi yang dikembangkan oleh Nikraz (2006) yaitu metodologi yang memfokuskan sistem multi agen ber-platform JADE.
Dalam pengembangan sistem berbasis agen, perlu dipertimbangkan kesesuaian agen untuk pemecahan masalah. Dari keseluruhan metodologi, dianggap bahwa agen telah menjadi pilihan untuk pemecahan masalah.
SPK multiagen investasi biodisel akan dikembangkan mengikuti metode pengembangan sistem dengan platform JADE seperti yang dikemukakan oleh (Nikraz, 2006) dengan kombinasi Roadmap. Alasan pengkombinasian ini adalah dalam Roadmap terdapat dengan jelas definisi atribut role pembentuk agen.
Kelemahan metode Roadmap diperbaiki oleh Nikraz dengan pendefinisian agen terlebih dahulu. Melalui metode ini pengembang dapat menangkap konsep utama dalam pembangunan sistem multiagen. Dalam pengembangan sistem ber-platform JADE, tahapan dilakukan seperti pengembangan perangkat lunak pada umumnya, yaitu analisis, desain, deployment dan uji coba.
Penelitian ini memfokuskan dua tahapan utama dalam pengembangan sistem, yaitu tahap analisis dan tahap desain. Dalam dua tahapan ini, dijabarkan dengan lengkap abstraksi dan konsep SPK multiagen dengan studi kasus SPK investasi biodisel. Dalam tahapan analisis, langkah awal yang dilakukan adalah penentuan konteks sistem untuk identifikasi awal agen dan role. Hasil akhir tahapan ini adalah dapat ditentukannya struktur agen yang telah mendapat proses perbaikan (refinement). Tahapan desain dilakukan untuk mendapatkan struktur agen internal. Dalam tahapan ini dilakukan pemisahan ataupun penggabungan agen. Hasil tahapan desain adalah mendapatkan struktur agen dan arsitektur
komunikasi yang dilakukan untuk kemudian dapat diimplementasikan menggunakan tools berplatform JADE.
Sebagi tahapan akhir pengembangan sistem adalah tahapan deployment Dalam keseluruhan metodologi sistem multiagen, tahap ini tidak dijabarkan secara detil. Menurut Arenas (2003) tahapan deployment untuk sistem multi agen dapat dibagi menjadi dua bagian, yaitu : tahap pendefinisian arsitektur sistem dan pembangunan antar muka pengguna. Tahapan deployment dalam pengembangan SPK multiagen dilakukan dengan memberikan gambaran teknis dalam JADE mengenai komponen utama sistem multiagen (agent, behaviour internal, interaksi dan ontologi).
Dalam kegiatan awal pengembangan SPK multiagen, terdapat asumsi sebagai pembatasan yaitu:
a. Definisi agen dalam SPK mulitagen sesuai dengan definisi agen yang telah dikemukakan oleh penelitian terdahulu mengenai sistem multiagen.
b. Platform JADE adalah platform yang dipilih untuk pengembangan.
c. Pembatasan jumlah agen sesuai dengan domain permasalahan.
d. Keamanan sistem tidak ikut dilibatkan dan dibahas dalam tiap proses pengembangan sistem.
4.2.1. Penentuan Skenario Sistem Penunjang Keputusan Multiagen dalam Tahapan Analisis
Pengembangan model SPK multiagen diawali dengan tahapan analisis untuk mendapatkan gambaran yang jelas mengenai permasalahan dengan tidak menekankan pada solusi. Seperti yang dikemukakan oleh Nikarz (2006), tahapan analisis diawali dengan penentuan skenario SPK multiagen. SPK investasi biodisel yang telah didefinisikan sebelumnya oleh Mariana (2005) merupakan SPK berbasis simulasi yang terdiri atas lima sub model yaitu kelayakan sumberdaya, kelayakan pasar, kelayakan teknis produksi, kelayakan finansial dan kelayakan lingkungan. Kelima sub model merupakan komponen pembentuk SPK yang dapat dijadikan elemen terpisah dengan perspektif kepentingannya masing- masing. Oleh karena itu, SPK ini dapat dimodelkan dengan pengembangan menjadi SPK berbasis agen. Interaksi yang serial antar sistem dan pengguna juga menjadi alasan pengembangan SPK investasi biodisel menjadi SPK berbasis agen.
Kemungkinan keterlibatan beberapa agen dalam sistem sesuai dengan asumsi yang dibuat pada awal tahapan kegiatan pengembangan menjadikan sistem berbasis agen tunggal menjadi sistem multiagen.
Dengan pembangunan kembali SPK investasi, Decision Maker (DM) dapat menentukan solusi yang feasible untuk melakukan investasi melalui akses tiap penentu kelayakan yang data dan modelnya disediakan oleh kontributor. Terdapat beberapa tipe DM, di antaranya DM sumberdaya, DM Finansial, DM Pasar, DM Produksi dan DM lingkungan. Dalam SPK terdahulu, kelima DM adalah sub model dalam SPK. Kontributor adalah penyedia data dan model, dan dapat berupa database, model base atau perangkat lunak lain yang telah ada untuk kemudian berkolaborasi sehingga didapatkan kemungkinan alternatif solusi bagi DM. DM dapat melakukan dua hal yaitu menerima atau memilih alternatif solusi yang ditawarkan serta menolaknya. Apabila DM menolak maka DM dapat menentukan skenario lain dengan data dan model yang disediakan oleh kontributor. Komunikasi antara agen dan kontributor dapat dilakukan dalam satu area ataupun dalam area terpisah. Di samping itu, komunikasi antar DM dan kontributor dapat dilakukan secara paralel sesuai dengan pola interaksi yang akan diidentifikasi kemudian.
Berdasarkan skenario yang telah dikemukakan, maka tahapan analisis dimulai dengan tahapan sebagai berikut :
1. Pembentukan diagram use case
Pembentukan use case dimaksudkan untuk mendapatkan kebutuhan fungsional yang potensial dari sebuah sistem baru. Metode Roadmap (Juan, 2002) dan metode berplatform JADE (Nikraz, 2006) mengemukakan bahwa penggambaran domain sistem dengan use case merupakan teknik yang efektif dan cukup jelas dalam menggambarkan kebutuhan sistem. Tiap use case merepresentasikan satu atau lebih skenario yang mendemonstrasikan bagaimana sistem berinteraksi dengan end user atau sistem lain untuk mencapai tujun tertentu. Diagram use case dapat digambarkan dengan notasi Unified Modelling Langauge (UML). Dalam notasi UML, terdapat dua komponen yang penting, yaitu aktor dan use case.
Untuk SPK investasi biodisel multiagen, terdapat dua aktor dan sembilan use case. Aktor dalam SPK multiagen investasi biodisel adalah decision maker dan kontributor sebagai penyedia data dan model. Secara rinci, aktor dan use case dapat digambarkan melalui diagram use case seperti pada Gambar 8.
Decision Maker
«uses»
Mengatur skenario
«uses»
Menanggapi hasil
Kontributor
Sistem Penunjang Keputusan Multiagen
Menentukan kelayakan pasar & sumberdaya
«uses»
Menentukan kelayakan teknis produksi
Menentukan kelayakan finansial
Menentukan kelayakan lingkungan
«uses»
«uses»
Menerima hasil skenario
Melakukan skenario lain
«extends» Penyediaan data
dan model
«uses»
«uses»
«uses»
«uses»
Berdasarkan diagram use case, aktor dapat melakukan fungsi yang berkaitan dengan tujuan aktor tersebut berinteraksi dengan sistem. Aktor DM dapat melakukan pengaturan skenario dan menanggapi hasil, sedangkan kontributor melakukan penyediaan terhadap data dan model dasar.
2. Identifikasi awal tipe agen yang terlibat
Tahapan ini dilakukan untuk menentukan tipe agen utama dari penurunan use case pada tahap 1. Berbeda pada metodologi Roadmap, dalam metodologi berplatform JADE, agen diidentifikasi sebelum pengidentifikasian role (responsibilities). Dalam tahapan ini akan dihasilkan diagram agen. Aturan yang diberlakukan untuk menentukan agen utama adalah sebagai berikut :
a. Menjadikan tiap user / device sebagai satu tipe agen.
Gambar 8 Diagram use case untuk SPK investasi biodisel multiagen
b. Menjadikan tiap sumberdaya (perangkat lunak atau aplikasi lain) sebagai satu tipe agen.
Dengan memberlakukan aturan tersebut, berdasarkan diagram use case yang telah dihasilkan pada tahapan sebelumnya, dapat diidentifikasi dua agen awal.
Agen-agen tersebut adalah : (1) Agen decision maker (DM). Agen ini diperoleh dari user atau aktor decision maker pada diagram use case. (2) Agen penyedia data dan sub model. Tipe agen ini diperoleh berdasarkan aplikasi atau perangkat lunak penyedia data dan sub model. Dalam SPK investasi oleh Mariana (2005), terdapat aplikasi pendukung untuk menentukan hasil sub model, yaitu aplikasi penentuan bahan dan energi yang diperlukan. Selain itu, penentuan hasil sub model lain misalnya sumberdaya dapat dilakukan melalui aplikasi pendukung lain. Aplikasi pendukung ini kemudian dapat dijadikan salah satu tipe agen yang terpisah dari agen user. Berdasarkan dua agen awal yang telah teridentifikasi, maka pada dapat dihasilkan diagram agen seperti yang disajikan pada Gambar 8.
Berdasarkan Gambar 9 terdapat dua tipe agen utama yaitu agen DM dan agen penyedia data dan model. Dalam diagram agen terdapat empat entitas utama, dengan penjelasan sebagai berikut :
1. Tipe agen
Entitas ini menunjukkan tipe agen yang aktual dan direpresentasikan dengan simbol lingkaran.
2. Human
Entitas ini dapat dikatakan sebagai personal yang harus berinteraksi dengan sistem selama proses operasional sistem. Simbol yang digunakan untuk merepresentasikan entitas ini adalah simbol aktor dalam notasi UML.
Agen Decision
Maker
Decision
3. Sumberdaya
Entitas sumberdaya merupakan sistem eksternal yang harus berinteraksi dengan sistem selama proses pengembangan dan direpresentasikan dengan segiempat.
4. Acquiantances
Acquiantances merupakan entitas yang dapat melakukan interaksi sosial dan direpresentasikan dengan panah. Entiti ini menunjukkan komunikasi yang dilakukan selama operasi. Komunikasi dapat dilakukan antar agen, antar agen dan human, maupun antar agen dan sumberdaya. Bagaimana teknik komunikasi untuk berinteraksi dilakukan belum ditentukan dalam tahapan ini.
Salah satu yang perlu mendapat perhatian dalam interaksi dalam sistem multiagen adalah interaksi yang dilakukan antara sistem eksternal dan human dengan agen.
Hal ini mengingat komunikasi yang dilakukan antara entitas tersebut tidak mempunyai penamaan maupun sintaks yang seragam (Nikraz, 2006).
Terdapat tiga cara dalam menentukan teknik yang dilakukan agen untuk berinteraksi, yaitu :
a. Penggunaan transducer agen
Agen Data dan
Model Aplikasi
penyedia data dan sub
model
(a). Agen yang diturunkan dari aktor Decision
(b). Agen yang diturunkan dari aktor kontributor
Gambar 9 Tipe agen utama
Agen transducer adalah sebuah agen yang berlaku sebagai interface antara agen dengan aplikasi/sistem software. Dalam cara ini, agen transducer menerima pesan dari agen-agen dalam sistem dan menerjemahkan pesan tersebut dan meneruskannya ke aplikasi/sistem lain. Komunikasi juga dapat dilakukan melalui arah sebaliknya. Format komunikasi yang dilakukan agen transducer dapat mengikuti teknik leksikal (Guha, 2002).
b. Penyisipan wrapper
Dalam teknik ini kode disisipkan ke dalam sistem / aplikasi lain.
Kode ini kemudian dapat berkomunikasi dalam bahasa agen.
c. Penulisan kode kembali
Teknik ini merupakan teknik paling ekstrim yang melibatkan penulisan kembali untuk menyerupai operasi dan kemampuan sumberdaya dengan kemampuan untuk berkomunikasi melalui bahasa komunikasi agen.
Ketiga cara tersebut dapat dideskripsikan pada Gambar 10.
3. Identifikasi responsibility
Dalam tahapan ini, responsibility tiap agen didefinisikan dalam bentuk yang informal dan mudah dicerna. Pada metode Raodmap dan Gaia (Wooldridge, 2000) responsibilities dikenal juga dengan istilah role. Berbeda pada metodologi sebelumnya, metodologi berplatform JADE melakukan identifikasi role sebelum identifikasi agen. Hal ini mempermudah proses identifikasi dikarenakan apabila agen ditentukan berdasarkan agregasi role yang berkaitan, hal ini dipandang tidak intuitif. Dalam beberapa kasus, sulit untuk menentukan bagaimana role dapat membentuk agen dan bagaimana penentuan agen yang tercakup dalam role yang telah ditentukan. Dengan mengidentifikasikan agen kemudian diturunkan responsibilities atau role-nya, maka ambiguitas yang terjadi dapat direduksi.
Terdapat aturan yang harus diterapkan dalam pembentukan tabel responsibility. Aturan tersebut adalah :
- Menurunkan responsibility tiap agen dari use case yang diidentifikasi pada tahap 1.
- Mengutamakan identifikasi pada agen-agen yang mempunyai responsibility lebih jelas dan menunda identifikasi responsibility untuk agen lain pada langkah berikutnya.
Berdasarkan diagram agen pada Gambar 9, maka dapat dihasilkan tabel responsibility sebagai berikut :
Tabel 1 Tabel responsibility untuk kasus SPK multiagen investasi biodisel
Tipe agen Responsibility Decision
Maker(DM)
Mengatur skenario untuk kelayakan produksi Mengatur skenario untu kelayakan sumberdaya dan pasar
Mengatur skenario untuk kelayakan finansial Mengatur skenario untuk kelayakan lingkungan Merespon request antar DM
Dalam Tabel 1 terlihat bahwa identifikasi responsibility dilakukan pada agen DM. Hal ini mengikuti aturan pertama dikarenakan responsibility yang diperoleh lebih jelas sedangkan untuk agen berikutnya ditentukan kemudian.
Gambar 10 Teknik interaksi antara agen dengan entitias lain (Nikraz,2006)
4. Identifikasi acquaitance
Dalam tahap ini, fokus kegiatan yang dilakukan adalah penentuan interaksi antar agen. Diagram agen diperbaiki dengan menambahkan relasi acquaitance yang sesuai untuk menghubungkan agen apabila dibutuhkan satu atau lebih interaksi antar agen tersebut. Gaia (Wooldridge, 2000) mempelopori istilah acquaitance, dan digunakan juga dalam Roadmap (Juan, 2002) dan (Nikraz) 2006.
Dalam kasus SPK investasi, relasi acquaintance dibutuhkan antar agen DM yaitu user produksi, user ketersediaan sumberdaya, user pasar, user finansial dan user lingkungan. Data yang didistribusikan antar user agen DM disimpan dan diambil serta dimanipulasi melalui kontributor, yaitu aplikasi penyedia data dan model. Oleh karena itu terdapat relasi acquaintance antar agen DM dan agen data dan model.
Berdasarkan analisis tersebut, maka dalam tahap 3 yaitu pengidentifikasian responsibility dapat diulangi kembali untuk mendapatkan tabel responsibility yang lebih lengkap (Tabel 2) sesuai dengan acquaitance yang telah diidentifikasikan sebelumnya.
Dengan adanya acquaitance yang diidentifikasikan dalam tahap 4, maka diagram agen yang telah diperoleh diubah untuk kemudian diperoleh gambar relasi antar agen yang lebih jelas. Gambar 11 menunjukkan diagram agen yang telah diperbaiki.
Tabel 2 Tabel responsibility setelah relasi acquaitance diidentifikasi Tipe Agen Responsibilities
Decision Maker 1. Mengatur skenario untuk kelayakan produksi
2. Mengatur skenario untu kelayakan sumberdaya dan pasar 3. Mengatur skenario untuk kelayakan finansial
4. Mengatur skenario untuk kelayakan lingkungan 5. Merespon request antar DM
6. Mengirimkan data ke user produksi (DM bidang produksi) 7. Mengirimkan data ke user ketersediaan sumberdaya (DM
bidang ketersediaan sumberdaya)
8. Mengirimkan data ke user finansial (DM bidang finansial) 9. Mengambil data dari agen penyedia data dan model
10. Mengambil penjelasan dan advice dari agen manajemen Tipe Agen Responsibilities
Penyedia data dan model
1. Merespon permintaan dari agen decision maker untuk hasil tiap sub model
2. Mengirimkan permintaan data dan model untuk agen DM
Dalam metodologi Gaia atau Roadmap role / responsibility yang didefinisikan merupakan suatu hal yang konseptual dengan penggambaran konsep yang abstrak. Dalam sistem berplatform JADE responsibility menjadi suatu hal yang lebih kongkret dengan pendefinisian yang lebih detil mengikuti metodologi Gaia. Berdasarkan metodologi Roadmap, maka terdapat beberapa atribut untuk role/responsibility, yaitu :
1. Fungsionalitas, yang terdiri atas dua properti, yaitu liveness dan safety 2. Permission
3. Activity 4. Protokol
Berdasarkan karakteristik tersebut maka dapat dijabarkan model responsibility untuk SPK investasi multiagen. Salah satu model role untuk pengaturan skenario adalah sebagai berikut:
Gambar 11 Agen diagram setelah tahap 4
Agen Decision
Maker
Decision Maker
Agen Data dan
Model Aplikasi
penyedia data dan sub
model
Secara lengkap, model responsibility disajikan dalam Lampiran 2
5. Perbaikan agen
Pada tahap 2, agen yang diidentifikasi adalah tipe agen awal. Dalam metodologi pengembangan sistem berbasis agen, kegiatan iterasi khususnya untuk pembaruan yang telah diperoleh dalam suatu tahapan merupakan hal yang penting untuk menghasilkan sebuah sistem yang handal. Perbaikan agen akan mempengaruhi responsibility dan relasi acquaintance. Untuk perbaikan agen, terdapat beberapa pertimbangan yang dapat diterapkan. Pertimbangan tersebut adalah :
1. Dukungan : mendefinisikan informasi dukungan yang dibutuhkan agen untuk melakukan responsibilitynya dan menspesifikasikan bagaimana, kapan dan dimana informasi tersebut dihasilkan atau disimpan.
2. Discovery : bagaimana agen-agen dihubungkan dengan sebuah relasi acquaitance. Relasi ini diperlukan agar agen dapat saling mencari atau melakukan uploading service yang disediakan oleh agen tertentu.
3. Manajemen dan monitoring : sistem yang dibutuhkan untuk memantau keberadaan agen atau mulai dan berhentinya agen.
Dalam SPK investasi, pertimbangan yang memungkinkan untuk proses perbaikan agen adalah discovery. Pertimbangan ini dapat menggunakan fasilitator direktori (Directory facilitator) yang terdapat dalam JADE. Melalui fasilitas ini agen dapat melakukan register service (layanan) yang dimiliki atau agen juga dapat mencari layanan yang disediakan oleh agen tertentu. Dalam kasus SPK investasi multiagen, setiap agen yang juga mewakili user DM dapat melakukan identifikasi user DM yang lain untuk kemudian melakukan registrasi hasil
Responsibility : Pengaturan skenario
Deskripsi : Melakukan pengaturan skenario untuk salah satu aspek kelayakan dengan mendapatkan acquaintance dari agen lain.
Protokol dan aktivitas :
Tampilkan list parameter.Input parameter.
Permission : baca, update Fungsionalitas :
Liveness : pengaturan skenario = (tampilkan list parameter.input parameter)ω Safety : true
inferensi. Agen lain seperti penyedia data dan model dapat melakukan registrasi atau up-loading, layanan penyediaan data dan model. User agen DM juga dapat melakukan pencarian terhadap layanan-layanan yang disediakan agen lain.
Berdasarkan hal ini, agen yang telah diidentifikasi pada tahap 2 dapat diperbaiki dengan penambahan dua agen baru, yaitu agen fasilitator direktori dan agen manajemen yang melakukan proses inferensi dan penjelasan. Agen penjelasan ini diperlukan dalam SPK sebagai dukungan DM dalam pengambilan keputusan (Ossowski, 2004). Informasi yang disediakan agen manajemen dapat diakses oleh semua user agen DM. Berdasarkan identifikasi lanjutan inilah maka dapat dihasilkan diagram agen baru seperti yang disajikan pada Gambar 12.
Berdasarkan diagram agen pada Gambar 12, maka dapat diperoleh tabel responsibility baru hasil revisi diagram agen. Tabel 3 menunjukkan tabel responsibilities untuk penambahan dua agen.
Agen Decision
Maker Decision Maker
Agen Data dan
Model Aplikasi
penyedia data dan sub
model
Gambar 12 Diagram agen yang telah diperbaiki
Agen FD Agen
Manaje men
Tabel 3 Tabel resposibility hasil perbaikan agen
Tipe Agen Responsibilities
Decision Maker 1. Mengatur skenario untuk kelayakan produksi
2. Mengatur skenario untu kelayakan sumberdaya dan pasar 3. Mengatur skenario untuk kelayakan finansial
4. Mengatur skenario untuk kelayakan lingkungan 5. Merespon request antar DM
6. Mengirimkan data ke user produksi (DM bidang produksi)
7. Mengirimkan data ke user ketersediaan sumberdaya (DM bidang ketersediaan sumberdaya)
8. Mengirimkan data ke user finansial (DM bidang finansial)
9. Mengambil data dari agen penyedia data dan model 10. Mengambil penjelasan dan advice dari agen manajemen 11. Mendapatkan agen penyedia data dan model serta agen
manajemen dari fasilitator direktori.
Penyedia data dan model
1. Merespon permintaan dari agen decision maker untuk hasil tiap sub model
2. Mengirimkan permintaan data dan model untuk agen DM 3. Melakukan registrasi pada fasilitator direktori
Manajemen 1. Merespon permintaan dari agen decision maker untuk hasil tiap sub model
2. Mengambil data dan model dari agen penyedia data dan model
3. Mengirimkan permintaan hasil inferensi untuk agen DM 4. Melakukan registrasi hasil inferensi pada fasilitator
direktori
6. Agen Deployment Information
Tujuan utama pembuatan diagram ini adalah untuk mendefinisikan kebutuhan dasar deployment yang kemudian akan dirujuk dalam proses desain.
Selain itu, pembentukan agen deployment dimaksudkan untuk membuat komunikasi antar komponen menjadi lebih efektif.
Berdasarkan domain SPK investasi yang telah didefinisikan, maka dapat dihasilkan diagram agen deployment yang disajikan pada Gambar 13 Gambar 13(a) memperlihatkan bahwa agen DM berada dalam sistem pengakses. Hal ini berarti setiap data yang dikirimkan ke dan dari user agen DM dapat diakses dari tiap-tiap posisi user berada. Komunikasi dapat melalui device tertentu. Gambar 13(b) menunjukkan bahwa setiap data dan model dan inferensi rule berada di
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 / penggabungan/penamaan agen
Tahapan pertama dalam desain sistem multiagen adalah pemisahan/penggabungan agen. Pemisahan/penggabungan 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 1(satu) 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 penambahan/penggabungan 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 role/responsibility, 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, 1(satu) predikat atau relasi dan 1(satu) 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
