Ta

1

BAB I  PENDAHULUAN

1.1  Latar Belakang       

Dewasa   ini   penggunaan   agen   dirasakan   cukup   membantu   di   berbagai 

bidang kehidupan. Hal ini dikarenakan  agen dapat berfungsi sebagai wakil atau  asisten yang dapat melakukan suatu pekerjaan tanpa  atau dengan sedikit kontrol  dari pengguna, sehingga pengguna bisa berkonstentrasi pada pekerjaan lain. Akan  tetapi   kebanyakan   agen   yang   digunakan,   masih   terbatas   artinya   ia   tidak  dapat  membuat dan memperbaharui pengetahuannya melalui pengalaman­pengalaman  selama ia mengerjakan suatu tugas tertentu. Akibatnya penerapan agen hanya bisa  dilakukan   pada   wilayah   wilayah   penerapan   di   mana   manusia   memiliki  pengetahuan yang lengkap tentang hal tersebut. Salah satu solusi dari masalah di atas adalah menggunakan  reinforcement   learning hierarchical neuro fuzzy politree.  Reinforcement learning hierarchical   neuro   fuzzy   politree  adalah   suatu   model   neuro­fuzzy   yang   bisa   melakukan  pembelajaran dan menghasilkan aturan­aturan (pengetahuan) melalui aksi/output  yang   dihasilkan   sebelumnya   dan   umpan   balik   dari   lingkungan   mengenai   aksi  tersebut.

2 Kadang   kala   pengguna   sistem   operasi   Linux   memaksa   menginstal  software  menggunakan   rpm   di   mana  dependency  (paket  software  lain   yang  dibutuhkan) belum tersedia secara lengkap atau secara tidak sengaja file­file yang  merupakan kebutuhan suatu software terhapus. Akibatnya tentu fatal software tadi  tidak akan bisa bekerja normal dan bisa saja software sama sekali tidak akan bisa  bekerja.  Ada   dua   pilihan   yang   bisa   diambil   pengguna   dalam   masalah   ini   yaitu  menghapus  software  ini   atau   melengkapi  dependency  nya.   Akan   tetapi   ada  masalah lain yaitu pengguna harus meluangkan waktu yang tidak sedikit untuk  mencari tahu software­software apa saja yang mengalami masalah ini, dan untuk  pengguna   awam   melakukan   hal   yang   membutuhkan   kemampuan   administrasi  Linux mendalam tentu sangat menyulitkan. Dan lagi pengguna belum tentu tahu  apakah software­software tersebut sebenarnya ia butuhkan atau tidak. Reinforcement   learning   hierarchical   neuro   fuzzy   politree  merupakan  konsep   baru   yang   belum   banyak   diterapkan.   Pada   tulisan   ini   akan   dicoba  penerapan   reinforcement learning hierarchical neuro fuzzy politree  pada agen  pengontrol  software  RPM yang memiliki  dependency  kurang lengkap, di mana  agen akan bergerak membuat pengetahuan sendiri berdasarkan umpan balik dari  penggunanya.   Agen   akan   memantau  software­software  yang   memiliki 

3 dependency kurang atau tidak lengkap, memantau kebiasaan user dalam memakai  software,   lalu   akan   memberikan   saran   sebaiknya  software  yang   mengalami  masalah dependency tadi dilengkapi atau sebaiknya dihapus saja.

1.2  Permasalahan Dari beberapa uraian   singkat   di   atas   dapat   dirumuskan   permasalahan  yaitu: bagaimana menerapkan konsep reinforcement learning hierarchical neuro   fuzzy politree pada agen pengontrol software RPM (Rpm Package Manager) yang  memiliki dependency kurang lengkap. 

1.3  Batasan Masalah Adapun batasan permasalahan dalam tugas akhir ini adalah: 1. Agen hanya akan hidup pada komputer yang berdiri sendiri bukan pada  sistem jaringan. 2. Agen hanya akan hidup pada sistem operasi Linux berbasis RPM (Fedora,  Suse, Mandriva). 3. Dependency  pada   skripsi   ini   didefinisikan   sebagai   paket  software  lain  yang dibutuhkan sehingga suatu software bisa digunakan.

4 4. Input yang digunakan sebagai dasar pemberian saran dibatasi hanya dua  yaitu lama pemakaian paket  software  dengan nama yang mirip dan lama  pemakaian paket software dengan grup yang sama dengan software yang  memiliki dependency kurang lengkap.

1.4 Tujuan Penelitian Penelitian   ini   bertujuan   mencoba   penerapan  reinforcement   learning   hierarchical   neuro   fuzzy   politree  pada   agen   pengontrol  software  RPM   (Rpm  Package Manager) yang memiliki dependency kurang lengkap. 

1.5 Manfaat Penelitian Adapun manfaat yang bisa diambil dalam penelitian ini adalah: 1. Memberikan   gambaran   mengenai   penerapan   model  reinforcement   learning   hierarchical neuro fuzzy politree pada software agen. 2. Membantu pengguna Linux dalam mengetahui  software  RPM yang memiliki  dependency kurang lengkap. 3. Membantu   pengguna   Linux   memutuskan   apakah  software  RPM   yang  dependencynya   kurang   lengkap   tersebut   sebaiknya   dihapus   atau   dilengkapi  dependency nya.

5 1.6 Tinjauan Pustaka Flavio   Joaquim   de   Souza,   Marley   M.R.   Vellasco,   dan   Marco   Pacheco  (Souza,   2002)  dari   universitas   Rio   de   Jaeniro   melakukan   penelitian   tentang  hierarchical neuro fuzzy quadtree models. Pada penelitian tersebut diperkenalkan  model  hierarchical neuro fuzzy quadtree models    yang merupakan model neuro  fuzzy yang menggunakan  Quadtree partioning  secara rekursif untuk mengatasi  masalah   struktur   yang   tetap   dan   jumlah  input  yang   terbatas.  Selain   itu   Karla  Figuerido, Marrey Vellasco, Marco Pacheco, dan Flavio Souza (Figuerido, 2004)  dari   universitas   Rio   de   Jaeniro     dalam   karyanya  Reinforcement   Learning_Hierarchical Neuro­Fuzzy Politree Model for Control of Autonomous   Agents  membahas tentang bentuk gabungan antara  Reinforcement Learning  dan  Hierarchical Neuro­Fuzzy Politree  di mana dengan model ini agen bisa secara  otomatis mempelajari struktur  neuro fuzzy  dan secara otonom mempelajari aksi  yang   harus   dilakukan.  Penelitian   lainnya   dilakukan   oleh   Priscilla   Diaz,   Karla  Figuerido, Marrey Vellasco,  Marco Aurelio Pacheco, dan Carlos Barbosa (Dias,  2004). Pada penelitian ini dilakukan sedikit modifikasi pada model  reinforcement   learning hierarchical neuro fuzzy politree yaitu pada nilai probabilitas awal untuk  memilih aksi secara acak yang tidak boleh terlalu kecil dan nilai ini harusnya  bertambah dan berubah sesuai dengan evolusi model.

6 1.7 Metodologi Penelitian 1. Studi Literatur Tahapan untuk memperdalam teori dan mencari referensi­referensi yang  berkaitan   dengan   tema   tugas   akhir   ini.   Sumber   referensi   berasal   dari  artikel berupa e­book, jurnal, skripsi, thesis, disertasi, dan buku. Tahapan  ini   sangat   penting   karena   digunakan   untuk   menunjang   tahapan­tahapan  berikutnya dalam tugas akhir ini. 2. Analisis Kebutuhan Tahap ini untuk menganalisa apa saja kebutuhan untuk penelitian tugas  akhir.  Seperti   pengumpulan   data,   analisa   data,   dan   analisa   kebutuhan  hardware dan software. Tahapan ini sangat penting untuk menunjang pada  tahapan perancangan sistem. 3. Perancangan Sistem Pada tahap ini, dimulainya pembuatan rancangan sistem. Mulai dari desain  model  reinforcement   learning   hierarchical   neuro   fuzzy   politree,   desain  agen,   dan   desain  interface  yang   dibutuhkan   pada   sistem.   Hasil   pada  tahapan ini akan dilanjutkan pada tahapan implementasi sistem. 4. Implementasi Sistem

7 Pada   tahap   ini,   dilakukan   pengimplementasian   rancangan   yang   telah  disusun pada tahap sebelumnya sesuai konsep yang telah dibuat. Sistem  dapat   mengalami   perubahan   konsep   dari   rancangan   sebelumnya   pada  tahapan ini, jika dirasa memerlukan penggantian. 5. Testing Sistem Pada   tahapan   ini   dilakukan   pengecekan   apakah   sistem   memiliki  kemampuan seperti yang diharapkan. 

1.8 Sistematika Penulisan Sistematika penulisan adalah sebagai berikut:  1. Bab I Pendahuluan Pendahuluan   akan   menguraikan   secara   dan   singkat   mengenai   latar   belakang masalah, batasan masalah, tujuan penelitian, manfaat penelitian  dan sistematika penulisan. 2. Bab II Dasar Teori Dasar teori menerangkan teori­teori dasar yang digunakan sebagai acuan  dari penelitian ini. Teori­teori tersebut meliputi konsep agen dan model   reinforcement   learning   hierarchical   neuro   fuzzy   politree,   penjelasan   mendalam tentang  reinforcement learning  dan    politree partioning. Dan  

8 mengenai algoritma pembelajaran yang digunakan sistem  reinforcement   learninghierarchical neuro fuzzy politree model.  3. Bab III Analisis dan Rancangan Sistem Membahas rancangan agen baik yang akan berinteraksi dengan pengguna  (melakukan pengawasan) maupun agen yang melakukan pembelajaran dan  pemberian saran, perancangan reinforcement learning hierarchical neuro  fuzzy politree dan Unified Model Language dari sistem. 4. Bab IV Implementasi Sistem Berisi detail proses dari hal hal yang dirancang pada bab III. 5. Bab V Pengujian dan Hasil Berisi proses pengujian sistem, data pengujian, hasil dari pengujian, dan  kesimpulan dari hasil pengujian. 6. Bab VI Penutup Berisi kesimpulan dan saran.

9

BAB II DASAR TEORI

2.1 Konsep Dasar Agen Agen   adalah   entitas  software  komputer   yang   memungkinkan  user  (pengguna) mendelegasikan tugas kepadanya secara mandiri (Caglayan,1997). Ada beberapa atribut dan karakteristik yang dimiliki oleh software agent   yang membuatnya berbeda dengan software komputer lainnya (Woolridge, 1995)  yaitu: 1. Autonomy,  Agent  dapat   melakukan   tugas   secara   mandiri   dan   tidak  dipengaruhi   secara   langsung   oleh  user,  agent  lain   ataupun   oleh  lingkungan     (environment).   Untuk   mencapai   tujuan   dalam   melakukan  tugasnya   secara   mandiri,  agent  harus   memiliki   kemampuan   kontrol  terhadap   setiap   aksi   yang   mereka   perbuat,   baik   aksi   keluar   maupun  kedalam . Dan satu hal penting lagi yang mendukung autonomy adalah  masalah intelegensi  (intelligence) dari agent. 2. Social Ability, Agen dapat berinteraksi baik dengan agen, lingkungan di  mana ia bekerja maupun dengan manusia.

10 3. Reactivity,  Kemampuan   untuk   bisa   cepat   beradaptasi   dengan   adanya  perubahan informasi yang ada dalam suatu lingkungan   (environment).  Lingkungan itu bisa mencakup:  agent  lain,  user, adanya informasi dari  luar. 4. Pro­activeness,  Agen   tidak   hanya   dituntut   bisa   beradaptasi   terhadap  perubahan   lingkungan,   tetapi   juga   harus   mengambil   inisiatif   langkah  penyelesaian apa yang harus diambil.

2.1.1  Klasifikasi agent menurut karakteristik yang dimiliki Teknik klasifikasi agent menurut karakteristik dipelopori oleh Nwana (Nwana,  1996).   Menurut   Nwana,  agent   bisa   diklasifikasikan   menjadi   tujuh   berdasarkan  pada karakteristiknya. Sof t ware Agent Collabor at ive Agent

React ive Agent Mobile Agent

I nf or mat ion and I nt er net Agent

Hybr id Agent

Het er ogeneous Agent Syst em I nt er f ace Agent

Gambar 2.1 Klasifikasi software Agent Menurut Karakteristik Yang Dimiliki

11 1. Collaborative Agent: Agent yang memiliki kemampuan melakukan kolaborasi  dan koordinasi antar agent dalam kerangka Multi Agent System  (MAS). 2. Interface   Agent:  Agent  yang   memiliki   kemampuan   untuk   berkolaborasi  dengan  user,   melakukan   fungsi  monitoring  dan  learning  untuk   memenuhi  kebutuhan user. 3. Mobile Agent: Agent yang memiliki kemampuan untuk bergerak dari suatu  tempat ke tempat lain, dan secara mandiri melakukan tugas ditempat barunya  tersebut, dalam lingkungan jaringan komputer. 4. Information   dan   Internet   Agent:  Agent  yang   memiliki   kemampuan   untuk  menjelajah internet untuk melakukan pencarian, pemfilteran, dan penyajian  informasi   untuk  user,   secara   mandiri.   Atau   dengan   kata   lain,   memanage  informasi yang ada di dalam jaringan Internet. 5. Reactive   Agent:  Agent  yang   memiliki   kemampuan   untuk   bisa   cepat  beradaptasi dengan lingkungan baru di mana dia berada. 6. Hybrid Agent: Kita sudah mempunyai lima klasifikasi agent. Kemudian agent  yang memiliki katakteristik yang merupakan gabungan dari karakteristik yang  sudah kita sebutkan sebelumnya adalah masuk ke dalam hybrid agent. 7. Heterogeneous   Agent   System:   Dalam   lingkungan  Multi   Agent   System  (MAS), apabila terdapat dua atau lebih hybrid agent yang memiliki perbedaan 

12 kemampuan dan karakteristik, maka sistem MAS tersebut kita sebut dengan  heterogeneous agent system. 2.1.2 Klasifikasi software Agent Menurut Lingkungan di mana Dijalankan Caglayan (Caglayan, 1997)  membuat suatu klasifikasi yang menarik mengenai  agent, yang berdasar kepada lingkungan  (environment) di mana agent dijalankan.

Software Agent Desktop Agent

Intranet Agent

Internet Agent

Gambar 2.2  Klasifikasi software Agent Menurut Lingkungan di mana Dijalankan Dari   sudut   pandang   di   mana   dijalankan,  software  agent   bisa   diklasifikasikan  sebagai  desktop agent,  internet agent  dan  intranet agent. Lebih jelasnya, daftar  dibawah menguraikan klasifikasi tersebut secara mendetail. 1. Desktop   Agent:  Agent  yang   hidup   dan   bertugas   dalam   lingkungan  Personal   Computer    (PC),   dan   berjalan   diatas   suatu  Operating   System  (OS). Termasuk dalam klasifikasi ini adalah: 1. Operating System Agent 2. Application Agent

13 3. Application Suite Agent 2. Internet Agent: Agent yang hidup dan bertugas dalam lingkungan jaringan  Internet,   melakukan   tugas   memanage   informasi   yang   ada   di   Internet.  Termasuk dalam klasifikasi ini adalah: 1. Web Search Agent 2. Web Server Agent 3. Information Retrieval Agent 3. Intranet Agent: Agent yang hidup dan bertugas dalam lingkungan jaringan  Intranet,   melakukan   tugas   memanage   informasi   yang   ada   di   Intranet.  Termasuk dalam klasifikasi ini adalah: 1. Collaborative Customization Agent 2. Process Automation Agent 3. Database Agent 4. Resource Brokering Agent 2.1.3 Arsitektur Software Agent Software  agent  dalam   konsepsi  black­box  bisa   divisualisasikan   sebagai  berikut.   Pertama  agent  mendapatkan  input  atau  perception  terhadap   suatu  masalah,   kemudian   bagian  intelligent   processing  mengolah  input  tersebut  sehingga bisa menghasilkan output berupa action  (Gambar 2.3).

14 I nt elligent Pr ocessing I nput (Per cept ion)

Out put (Act ion)

Gambar 2.3 Software Agent Secara Black­Box Dalam konsepsi  black­box, arsitektur  software  agent  bisa diterima oleh semua  peneliti,   karena   arsitektur   tersebut   bersifat   sangat   umum   dan   memungkinkan  mencakup semua jenis software agent.  Brenner   (Brenner,   1998)   mengemukakan   satu   model  intelligent   processing  untuk  software  agent  yang   berisi:  interaction,  information   fusion,  information processing dan action  (Gambar 2.4).

I nf or mat ion Fusion

I nf or mat ion Pr ocessing

Act ion

I nt er act ion

I nt er act ion

I nput (Percept ion)

Out put (Act ion)

I nt elligent Processing

Gambar 2.4 Proses Kerja software Agent Software  agent  memiliki   module   interaksi     (interaction   module)   yang  berguna   untuk   melakukan   komunikasi     (communication),   koordinasi  (coordination) dan kooperasi   (cooperation) dengan lingkungannya. Lingkungan  (environment) dari  agent  bisa berwujud  agent  lain,  user  atau pengguna, ataupun  berupa   sumber­sumber   informasi     (information   sources).  Agent  menggunakan  modul interaksi untuk mendapatkan informasi dari lingkungan dan juga untuk 

15 melakukan aksi. Oleh karena itu module interaksi disediakan dalam level  input  (perception) dan output  (action)  (Gambar 2.4). Informasi­informasi yang didapat dari proses interaksi dikumpulkan dalam  suatu tahapan klasifikasi  (ontology) yang tepat dalam knowledge­base. Misalnya  informasi hasil interaksi dengan  agent  lain, tentu mempunyai karakteristik dan  format yang lain dengan informasi yang didapat dari user   (pengguna). Disinilah  perlu dikembangkan strategi dan ontologi yang tepat untuk menyusun informasi  yang masuk. Tahapan ini disebut dengan information fusion  (Gambar 2.4). Kemudian   tahapan   berikutnya   adalah   tahapan     pengolahan   informasi  (information   processing).   Seperti   dijelaskan   sebelumnya,  agent  mempunyai  tujuan   (goal)  berhubungan  dengan tugas yang dibebankan kepadanya. Tujuan  pengolahan   informasi   disini   adalah   untuk   membuat   interpretasi   terhadap  informasi yang ada supaya dengan itu  agent  bisa berorientasi ke tujuan   (goal­ oriented)   yang   dibebankan   kepadanya.   Meskipun   tentu   saja   untuk   mencapai  tujuan   yang   ingin   dicapai,   harus   melewati   tahapan­tahapan   proses   seperti  planning, scedulling, dsb. Tahapan berikutnya adalah melakukan aksi   (action) berdasarkan kepada  tujuan     (goal),  planning,   dan  scedulling  yang   ada   pada  agent.   Seperti   sudah  dijelaskan   diatas,   agent   melakukan   aksi   dalam   lingkungannya,   sehingga 

16 bagaimanapun juga dia harus tetap memanfaatkan module interaksi  (interaction   module) dalam aksinya. 2.1.4 Metodologi Pengembangan Agen Nikrazla  (Nikraz1a, 2006)  membagi tahapan pembuatan  software  agent   ke dalam dua tahapan yaitu tahap analisis dan desain. Tahap analisis  meliputi  pembuatan  use   case,  identifikasi   awal   tipe   agen,   identifikasi   tugas   agen,  identifikasi perkenalan/hubungan antar agen, penyempurnaan agen, dan informasi  deployment 

agen.

 

Sedang

 

tahapan

 

desain

 

meliputi 

pembagian/penggabungan/penamaan   ulang   agen,   spesifikasi   interaksi,   definisi  protokol interaksi,  template  pesan, penjelasan untuk registered/searched (yellow   pages),  interaksi sumber daya agen, interaksi pengguna­agen, perilaku internal  agen, mendefinisikan ontology, dan seleksi bahasa isi (content language) 2.1.4.1 Analisis Tahapan analisis bertujuan untuk mengidentifikasi dan mengklarifikasi  tentang masalah masalah yang akan diselesaikan  1. Use Case,  Use   cases  adalah   cara   yang   efektif   untuk   menangkap   kebutuhan  fungsional   dari   sebuah   sistem.   Setiap  use   case  menampilkan   satu   atau  lebih skenario 

17 yang   mendemonstrasikan   bagaimana   sistem   seharusnya   berinteraksi  dengan pengguna atau sistem lainnya. 2. Identifikasi Awal Tipe Agen  Tahap ini meliputi identifikasi agen agen apa saja yang harus dibuat dan  pembuatan draft awal dari agent diagram. Pada tahapan ini ada beberapa  aturan   yang   harus   diikuti,   pertama   tambahkan   satu   agen   setiap  pengguna/alat dan yang kedua tambahkan satu tipe agen setiap sumber  daya. 3. Identifikasi Tugas Pada tahap ini, setiap agen yang telah diidentifikasi, dibuat daftar tugas  tugas yang harus ia kerjakan.  4.  Identifikasi Hubungan Pada tahap ini, difokuskan pada interaksi antar agen. Agen apa harusnya  berhubungan   dengan   agen   apa.   Pada   tahapan   ini  agent   diagram   diperbaharui dengan menambahkan relasi acquaintance yang tepat.  5. Penyempurnaan Agen Pada tahap ini agen agen yang telah diidentifikasi pada tahap 2 diperbaiki  dan disempurnakan. 6. Informasi Deployment Agen

18 Pada tahap ini diidentifikasi pada alat mana agen akan ditempatkan. Alat  yang dimaksud bisa berupa PC  (komputer personal), mainframe, ataupun  embedded device.

2.1.4.2 Desain Ketika masalah telah diketahui secara detail, langkah dilanjutkan pada  fase desain, yang bertujuan  untuk menspesifikasi solusi. Tidak ada batas yang  kuat   antara   dua   fase   ini   dan   selama   melakukan   proses   pada   fase   analisis   dan  desain, seorang dapat berpindah pindah dari fase satu ke fase yang lain 1. Pembagian/Penggabungan/Penamaan Ulang Agen Tahapan ini meliputi pengobservasian pada diagaram diagram yang telah  dihasilkan pada tahap analisis. Apakah suatu agen yang ada harus dibagi  atau   digabungkan.   Langkah   ini   penting,   karena   berpengaruh   terhadap  efisiensi sistem secara keseluruhan. 2. Spesifikasi Interaksi Pada tahap ini, untuk setiap agen, semua tugas yang berhubungan dengan  relasi acquaintance dengan agen yang lain, diterapkan pada agen dan tabel  interaksi dihasilkan dari setiap tipe agen.   3. Definisi Protokol Interaksi

19 Ketika memungkinkan, protokol interaksi yang didefinisikan oleh FIPA  harus diadopsi. Meskipun seringkali masalah pada interaksi membutuhkan  ad­hoc interaction protocol. 4. Template Pesan Semua   aturan   protokol   interaksi   yang   diidentifikasi   pada   langkah  sebelumnya diimplementasikan sebagai perilaku pada agen. Pada tahapan  ini, objek MessageTemplate yang sesuai akan digunakan untuk menerima  pesan   yang   masuk   dan  template   template  ini   ditambahkan   pada   tabel  interaksi. 5. Penjelasan untuk Registered/Searched (Yellow Pages) Pada tahap ini, konvensi nama dan layanan yang akan didaftar/dicari oleh  agen pada katalog yellow pages dibuat (jika relevan).  6. Interaksi sumber daya agen Seringkali terdapat kasus di mana atau atau lebih agen harus berinteraksi  dengan   sumber   daya   eksternal   seperti   basis   data,   sistem   berkas,   atau  perangkat lunak yang umum. Pada tahap ini diidentifikasi sumber daya  aktif dan pasif pada sistem dan bagaimana agen akan berinteraksi dengan  sumber daya sumber daya ini. 7. Interaksi pengguna­agen

20 Pada   tahapan   ini   didefinisikan   bagaimana   seharusnya   nanti   agen   akan  berinteraksi dengan pengguna. 8. Perilaku Internal Agen Pada tahap ini desainer sistem harus melihat pada tabel interkasi, sehingga  bisa mengidentifikasi perilaku perilaku masing masing agen. Berdasarkan  atas   tabel   tugas   yang   dihasilkan   pada   tahap   analisis,   tugas   tugas   agen  dipetakan   kepada   perilaku   agen.   Tipe   tugas   yang   berbeda   (termasuk  interaksi)   akan   membutuhkan   tipe   perilaku   agen   yang   berbeda   untuk  dispesifikasikan. 9. Mendefinisikan Ontology Ketika   agen   pada   sistem   berinteraksi,   mereka   bertukar   informasi.   Dan  kadang   informasi   tersebut   masih   berupa   objek   primitif   seperti   sebuah  String     (kalimat),   sebuah   angka   atau   malah   memiliki   struktur   yang  kompleks.   Untuk   itu   dibutuhkan  ontology  

 yang   tepat   untuk 

dispesifikasikan 10. Seleksi bahasa isi (content language) Pada tahapan ini akan dipilih  content language  yang sesuai dengan agen  yang dibangun. 

21 2.2  Reinforcement Learning Hierarchical Neuro­Fuzzy Politree  2.2.1  Reinforcement Learning  Reinforcement   Learning  adalah   pembelajaran   terhadap   apa   yang  dilakukan,   bagaimana   memetakan   situasi   terhadap   aksi   yang   dilakukan   untuk  memaksimalkan  sinyal  ganjaran.  Pembelajar  tidak  diberi  tahu  aksi  yang  mana  yang harus diambil, sebagaimana sebagian besar dari model  machine learning   yang lain, tetapi harus menjelajahi aksi yang mana menghasilkan ganjaran/reward  terbesar dengan cara mencobanya (Sutton , 1998).  Pada  reinforcement   learning,  pembelajar   menerima   umpan   balik  berdasarkan status kelayakan respon yang ia lakukan (aksi) terhadap lingkungan  di mana ia bekerja. Untuk aksi yang benar  reinforcement learning mirip dengan  pembelajaran   terbimbing   (supervised   learning)  di   mana   pada   keduanya  pembelajar   akan     diberitahu   bahwa   aksi   yang   dilakukannya   sesuai   atau  ganjarannya positif. Akan tetapi saat terjadi kesalahan/aksi yang dilakukan salah  terdapat   perbedaan   pada   keduanya,   pada   pembelajaran   terbimbing   jika   hal   ini  terjadi maka pembelajar akan langsung diberitahu tentang aksi apa yang harusnya  dilakukan pada kondisi tersebut, sedang pada reinforcement learning pembelajar  hanya akan diberi tahu bahwa aksi yang dilakukannya itu tidak sesuai dengan  memberikan   ganjaran   kecil   (negatif).   Pada   kehidupan   nyata  reinforcement  

22 learning lebih umum dibandingkan pembelajaran terbimbing. Jarang sekali terjadi  terdapat   guru   yang   dapat   mengatakan   apa   yang   seharusnya   dilakukan   ketika  terjadi kesalahan. 2.2.2  Sel Reinforcement Learning Neuro Fuzzy Politree 

   Sel Reinforcement Learning Neuro Fuzzy Politree  (selanjutnya disebut  RL­NFP) adalah sistem neuro­fuzzy mini yang menggunakan politree partioning   pada ruang yang diberikan berdasarkan fungsi keanggotaan yang diperlihatkan  pada gambar 2.6, di mana   ρ (x) dan µ (x) mewakili fungsi keanggotaan rendah   dan tinggi, sel RL­NFP menghasilkan  output  bulat setelah proses defuzzifikasi.  Nilai peubah masukan dibaca oleh agen dengan sensor lalu ditarik kesimpulan  pada antesenden himpunan fuzzy (rendah dan tinggi) (Figueiredo, 2004). (1)

Gambar 2.5: Rumus Fungsi keanggotaan  model RL_HNFP Setiap sel menerima semua  input  yang ada pada sebuah masalah. Untuk contoh  ilustrasi gambar 2.7 menggambarkan sebuah sell dengan dua  input  x1 dan x2.  Pada   gambar   2.7   setiap   partisi   dihasilkan   dari   kombinasi   dari   dua   fungsi  keanggotaan  ρ   (rendah)   dan   µ   (tinggi)   dari   setiap   variabel   masukan   yang   diasosiasikan dengan himpunan aksi (a1,a2,a3,....,at). 

23 Konsekuen dari partisi rendah maupun tinggi kemungkinan berasal dari  type  singleton  atau  keluaran   dari   fase  level  sebelumnya.  Meskipun  konsekuen  singleton  sederhana,   konsekuen   ini   sebelumnya   tidak   diketahui   karena   setiap  konsekuen  singleton  berasosiasi   dengan   sebuah   aksi   yang   belum   didefinisikan  sebelumnya.   Setiap   partisi   pada  poli­partition  memiliki   himpunan   aksi   yang  mungkin   sebagaimana   yang   ditunjukkan   pada   gambar   2.7,   dan   setiap   aksi  dihubungkan dengan sebuah  nilai Q. Nilai Q  didefinisikan sebagai jumlah dari  nilai ganjaran/reward  yang diharapkan. Nilai ini dihasilkan dari eksekusi aksi a  pada keadaan s.

Gambar 2.6  Representasi Internal RL­Neuro Fuzzy Politree Cell dengan dua  input Dengan   memakai   algoritma   pembelajaran  reinforcement   learning,  satu  aksi dari setiap poli partisi (contoh ai,aj,ap,dan aq) dipilih sebagai salah satu yang  mewakilili keadaan yang sesuai dari sistem ketika sistem ada pada keadaan yang  diberikan. Demikian konsekuen adalah aksi yang harus   dipelajari sebuah agen  selama tahap pemrosesan.

24 Intrepetasi linguistik dari pemetaan yang diimplentasikan oleh sel RL­NFP  ditunjukkan oleh gambar 2.7 diberikan pada himpunan aturan di bawah ini : rule1: If x1 ∈ ρ1 and x2 ∈ ρ2 then y = ai rule2: If x1 ∈ ρ1 and x2 ∈ µ2 then y = aj rule3: If x1 ∈ µ1 and x2 ∈ ρ2 then y = ap rule4: If x1∈ µ1 and x2 ∈ µ2 then y = aq

Gambar 2.7 Skema Sel Rl­NFP dan aturan yang dihasilkan Setiap   aturan   berhubungan   dengan   satu   dari   empat   poli­partisi   yang  dihasilkan   melalui   politree   partitioning.   Ketika   masukan   ada   pada   kuadran  (low,low),   aturan   1   memiliki   level   terbesar.   Setiap   kuadran   dapat   dibagi   lagi  menjadi empat bagian melalui sel RL­NFP yang lain. Metode defuzzifikasi yang paling sesuai untuk masalah ini adalah jenis  weighted average  karena ia mengkombinasikan konsekuen aturan fuzzy dengan  setiap nilai aturan yang ada. Lalu menghasilkan keluaran bulat (crisp) berdasarkan 

25 persamaan pada gambar 2.8 (2), di mana  αi adalah   firing level  dari aturan ke i  dan konsekuen ai adalah satu dari dua kemugkinan, yaitu singleton (ai=konstanta)  atau keluaran dari level sebelumya ai=ym, di mana ym mewakili keluaran dari sel  umum   m.   Karena   fungsi   keanggotaan   tinggi     (µ)   dan     rendah   (ρ)   saling   komplemen, maka proses defuzzifikasi dapat disederhanakan menjadi   (Gambar  2.8 (3)). 

Gambar 2.8 Metode defuzzifikasi pada sel RL­NFP 2.2.3  Arsitektur Reinforcement Learning Hierarchical Neuro Fuzzy Politree  Setelah   sel   dasar   dari   sistem   telah   dijelaskan,   RL­HNFP   model   dapat  dibuat   berdasarkan   interkoneksi   dari   sel   sel   ini.   Sel   RL­HNFP   membentuk  struktur hierarkis yang menghasilkan dari aturan aturan pada penalaran agen (lihat  gambar 2.10).  Pada arsitektur yang diperlihatkan pada gambar 2.9. poli partisi 1,3,4, m­1  belum dibagi menjadi subdivisi, jadi konsekuen dari aturan aturannya adalah nilai  a1,a2,a3,..am­1.   Di   lain   pihak   poli   partisi   2   dam   m   telah   dibagi   bagi,   jadi  konsekuen dari rule rule nya adalah keluaran dari sub sistem 2 dan m.

26

Gambar 2.9 Contoh arsitektur model Rl­HNFP Pada gilirannya, subsistem ini memiliki konsekuen (a21,a22,...a2m) dan  (am1,am2,...amm). Setiap ai berhubungan dengan level 0 sugeno (singleton) yang  mewakili aksi yang akan diidentifikasi (diantara aksi aksi yang mungkin), melalui  reinforcement learning.  Keluaran   dari   sistem   yang   diperlihatkan   gambar   2.9,   dihitung   dengan  persamaan: (4)

Gambar 2.10 Rumus defuzzifikasi model RL­HNFP Struktur keluaran dari y adalah gabungan aksi   (nilai bulat/crisp)  yang  haris dilakukan aktuator agen. Itulah mengapa model RL­HNFP membuat dan menghitung strukturnya dengan memetakan keadan keadaan pada aksi aksi yang  harus dilakukan. 

27 2.2.4  Algoritma   Pembelajaran  Reinforcement  Learning  Hierarchical  Neuro   Fuzzy Politree

 

Pembelajaran   neuro­fuzzy   pada   umumnya   dibagi   menjadi   dua   bagian 

yaitu:   identifikasi   struktur   dan   penyesuaian   parameter.   Model   RL­HNFP  melakukan kedua hal ini  pada satu langkah algoritma. Diagram alir algoritma pembelajaran ditunjukkan pada gambar 2.11 

Gambar 2.11 Algoritma pembelajaran model RL­HNFP Agen harus menjalankan banyak putaran/melakukan banyak  cycle  untuk  menyakinkan bahwa sistem/lingkungan di mana ia dimasukkan bisa  dipelajari.  Cycle  didefinisikan sebagai banyak langkah yang akan lakukan oleh agen pada  lingkungan dari titik di mana agen diinisialisasi sebelumnya menuju titik yang  diyakini sebagai tujuan agen. Proses   pembelajaran   dimulai   dengan   mendefinisikan   variabel   masukan   yang  relevan  pada   sistem/lingkungan  di   mana   agen   dimasukkan   dan   himpunan  aksi 

28 yang boleh digunakan dalam rangka mencapai tujuannya. Berikut ini algoritma  yang   digunakan  Reinforcement   Learning   Hierarchical   Neuro   Fuzzy   Politree   dalam melakukan pembelajaran: 1. Mengkonstruksi induk sel (sel akar) Sel   akan   dibuat   dengan   himpunan   fuzzy   yang   memiliki  domain  sama  dengan semesta pembicaraan variabel masukan xi. Nilai nilai variabel masukan  dibaca oleh sensor agen, dinormalisasi, dan   untuk setiap xi akan dihitung nilai  himpunan  fuzzy  rendah  dan  tinggi.  Setiap  poli  partisi  memilih  satu  aksi  (dari  himpunan   aksi),   berdasarkan   atas   metode   yang   dijelaskan   pada   langkah   4  algoritma ini. Keluaran sel digitung dengan proses defuzzifikasi yang diberikan  oleh persamaan pada gambar 2.8 (3). Keluaran dari sel ini akan dieksekusi oleh  aktuator agen. 2. Ganjaran Global Setelah  aksi   dilakukan,   lingkungan   dibaca   sekali   lagi.   Pembacaan   ini  memungkinkan   penghitungan   ganjaran   global   yang   akan   digunakan   untuk  mengevaluasi   aksi   yang   dilakukan   oleh   agen.   Nilai   ini   harus   dihitung   dengan  fungsi   evaluasi   yang   didefinisikan   berdasarkan   tujuan   agen.     Di   sini   fungsi  evaluasi   didefinisikan   tidak   hanya   disesuaikian   dengan   keadaan   asli 

29 reinforcement dengan memberi hadiah atau hukuman (1/­1), tetapi juga intensitas,  sehingga membuat proses pembelajaran menjadi lebih efisien. 3. Propagasi balik ganjaran Pada setiap langkah, ganjaran dihitung untuk setiap partisi dari semua aktif sel  berdasarkan partisipasinya pada aksi keseluruhan. Ganjaran keseluruhan dihitung  dengan fungsi evaluasi di propagasi balik dari sel akar ke sel sel daun berdasarkan  gambar 2.14 dan penghitungan yang diperlihatkan oleh rumus di bawah ini :  α01 = ρ0 (x1) . ρ0  (x2) α02 = ρ0  (x1) . µ0  (x2) α03 = µ0  (x1) . ρ0  (x2)  α04 = µ0  (x1) . µ0  (x2) (5)  R0ll = α01 . Rglobal   R0lh = α02 . Rglobal     R0hl = α03 . Rglobal      R0hh = α04 . Rglobal     (7) 

α11 = ρ1 (x1) . ρ1  (x2) α12 = ρ1  (x1) . µ1  (x2) α13 = µ1  (x1) . ρ1  (x2) α14 = µ1  (x1) . µ1  (x2) (6) R1ll = α11 . R0ll R1lh = α12 . R0ll R1hl = α13 . R0ll R1hh = α14 . R0ll (8)

Gambar 2.12 Rumus perhitungan ganjaran global Nilai   αi   dihitung   dengan   menggunakan   operator   T­norm   AND.  Persamaan 5 dan 6. untuk sel akar  (RL­HNFP0) dan turunannya  (RL­HNFP1).  Penghitungan   ganjaran   sel   Rl­HNFP0   dan   RL­HNFP1   didefinisika   oleh  Persamaan   7   dan   8     (R   global   adalah   ganjaran   global   yang   telah   dihitung  sebelumnya).

30

Gambar 2.13, Propagasi balik dari ganjaran global dari lingkungan untuk model  Rl­HNFP, di mana sel akar (RL_HNFP0) memiliki deskendan pada partisi  low/low 4. Pemilihan aksi Aksi   aksi   diasosiasikan   dengan   fungsi   nilai   Q   dan   komposisi   dari  himpunan   aksi   yang   dipilih   dan   dicobakan   selama  reinforcement   learning.   Penjelajahan ruang keadaan adalah langkah kunci untuk menemukan aksi aksi  yang berhubungan dengan respon terbaik agen (dalam mencapai tujuannya) ketika  ada pada suatu keadaan di lingkungan tertentu. Metode ∈­greedy akan digunakan  yang memilih aksi aksi yang bersesuaian dengan nilai Q tertinggi yang diharapkan  dengan kemungkinan (1­∈)  dan dengan kemungkinan  ∈  memilih aksi secara  acak. Nilai maksimum dari ∈  adalah 0.1.

31 5. Memperbaharui nilai  Q (st­1, at­1) Setelah penghitungan nilai ganjaran dari setiap sel di dalam struktur, nilai  Q yang bersesuaian dengan aksi yang telah memberi kontribusi kepada aksi secara  keseluruhan harus diperbaharui. Perbaharuan   ini   berdasarkan   evaluasi   antara   ganjaran   yang   didapatkan  sekarang   dan   sebelumnya.   Perbaharuan   nilai   Q   dilakukan   dengan   dua   bentuk:  ketika ganjaran global lebih tinggi dari ganjaran sebelumya maka nilai Q akan  ditambah.   Dan   akan   dilakukan   pengurangan   pada   nilai  ∈­greedy  yang  bersesuaian dengan setiap partisi untuk setiap sel aktif. Di lain pihak jika ganjaran  global sekarang lebih kecil dari ganjaran global sebelumnya maka akan dilakukan  pengurangan nilai Q untuk mengurangi pemilihan aksi ini ketika sel kembali aktif.  Nilai    ∈­greedy  lalu   akan   ditambah,   sehingga   memungkinkan   aksi   aksi   yang  berbeda akan dipilih ketika partisi ini aktif kembali. 6. Pemartisian Pemartisian   pada   sebuah   sel   dilakukan   ketika   partisi   memenuhi   dua  kriteria. Kriteria pertama adalah untuk mencegah struktur mengembang sebagai  hasil aksi aksi buruk yang diakibatkan oleh pemilihan aksi yang belum matang.  Kriteria kedua ketika ada variasi aksi yang signifikan pada fungsi nilai Q. Ketika  poli   partisi   memenuhi   dua   kriteria   di   atas.   Sel   daun   lalu   akan   dibuat   dan 

32 dihubungkan dengan poli partisi ini. Sel daun juga menerima himpunan aksi dari  pendahulunya. 

2.3 Rpm  (Rpm Package Manager) 2.3.1 Konsep  Package Manager Aplikasi pada sebagian besar sistem operasi terdiri atas beberapa file, yang  harus dikopi pada lokasi tertentu pada sistem berkas komputer sebelum aplikasi  tersebut bisa berjalan. Demikian halnya, pengguna komputer kadang butuh untuk  menghapus   software   dari   komputer   ataupun   memperbaharuinya   dengan   versi  yang lebih baru. Pada awalnya instalasi aplikasi baru pada sistem operasi Linux  merupakan proses yang cukup kompleks, karena aplikasi didistribusikan dalam  bentuk kode sumber. Untuk menginstal aplikasi baru, seperti Apache Web Server  , kode sumber aplikasi harus didownload terlebih dahulu (biasanya dalam bentuk  format   kompresi)   lalu   di   ekstrak.   Setelah   itu   dikonfigurasi   untuk   mendukung  sistem yang diinginkan, dikompilasi, dan menginstal nya dengan menaruh semua  komponen nya (program, dokumentasi, file konfigurasi, dan lain lain) pada lokasi  yang benar dan mengeset hak akses pada semua  file tersebut. Untuk menghapus  aplikasi   pengguna   berarti   harus   melakukan  reverse  proses   di   atas.   Dengan  menghapus file­file yang dikopi ke dalam sistem file. Proses di atas memang tidak  sulit.   Tetapi   bayangkan   jika   harus   mengurusi   ratusan   sampai   ribuan   aplikasi. 

33 Sistem Red Hat Linux 7.3 yang diinstal secara penuh menyediakan 3000 program  dan lebih dari 160.000 total file. Bayangkan pengguna mencoba untuk mengingat  dan secara manual menghapus semua file itu. Package   Manager  merupakan   alat   bantu   untuk   menangani/menginstal  aplikasi di beberapa distro. Package Manager pada Linux menyediakan software   yang mengatur kompilasi  software  sehingga menghasilkan paket dari  software   yang mereka kompilasi. Paket ini berupa berkas  yang terkompresi yang berisi  koleksi file yang berhubungan (file executable, pustaka, dan lain lain) dan berkas  yang menyediakan informasi tentang berkas tersebut berkaitan dengan instalasi,  pengaturan   berkas­berkas,   serta   paket   lain   yang   dibutuhkan   jika   ada.   Sebagai  contoh paket Postfix berisi 275 berkas dan  file  yang menspesifikasikan dimana  275 berkas tersebut harus ditempatkan. Sebagai tambahan, manajemen paket pada  Linux memiliki sebuah basis data komponen yang melacak berkas dan aplikasi  yang   telah   diinstal   menggunakan   aplikasi   manajemen   paket.   Hal   ini   untuk  membantu package manager melakukan pekerjaannya. 2.3.2 Konsep Dasar RPM (RPM Package Manager) Rpm merupakan salah satu alat Package Manager pada Linux. Rpm pada  awalnya   dinamakan  RedHat   Package   Manager  tetapi   setelah   digunakan   oleh  distribusi Linux yang lain, nama nya berganti menjadi rpm Package Manager. 

34 Untuk menginstal program yang berbasis Rpm dibutuhkan  file  yang berekstensi  *.rpm.   Di   bawah   ini   diberikan   beberapa   contoh   perintah   rpm   yang   biasa  digunakan beserta penjelasannya.  Perintah

Penjelasan

Hak akses

rpm ­ivh .rpm Menginstall   paket   .rpm  Root dengan mencetak keluaran perintah ke  layar rpm ­i .rpm

Menginstall   paket   .rpm  root tanpa   mencetak   keluaran   perintah   ke  layar

rpm   ­i   –nodeps  Menginstall   paket   .rpm  Root .rpm dengan   mengabaikan   pengecekan  tehadap   software   yang   dibutuhkan  (dependency)  rpm   .rpm

­Uvh  Mengupdate   paket     root dengan   .rpm   dan  mencetak keluaran perintah ke layar

rpm ­e 

Menghapus/Menguninstall  paket  root  dari basis data rpm

rpm ­qa

Mencetak ke layar daftar semua paket  pengguna yang telah terinstal biasa

rpm ­qf 

Mencetak   ke   layar   paket   asal   dari  pengguna biasa

rpm ­Va ­­nofiles

mencetak ke layar  software  rpm yang  pengguna dependency­nya   kurang   dan  software  biasa apa saja yang ia butuhkan. 

Tabel 2.1 Tabel perintah rpm beserta kegunaannya Paket rpm (file  *.rpm) merupakan berkas yang berisi aplikasi dan semua berkas  yang dibutuhkan aplikasi tersebut. Sebagai contoh Apache Web Server terdiri dari 

35 beberapa berkas konfigurasi, sejumlah berkas dokumentasi, dan Apache server itu  sendiri semuanya ada dalam satu paket RPM, serta informasi bagaimana apache  akan diinstal dan dependensi yang ia butuhkan.   Setiap paket yang diinstal dengan  Rpm direkam dalam basis data. Sistem  Rpm menyediakan perintah untuk mengquery  isi basis data untuk mencari tahu  paket   apa   yang   telah   diinstal   dan   menyediakan   informasi   detail   tentang   paket  paket itu.  2.3.3 RPM API (Application Programming Interface) Rpm   menyediakan   pustaka   api   (application   programming   interface)  sehingga perintah perintah rpm baik instalasi maupun query bisa dilakukan dalam  program. Alasannya sederhana bahwa perintah Rpm dibuat dengan pustaka Rpm  ini   dan   pustaka   pustaka   yang   sama   tersedia   untuk   digunakan   dalam   program.  Pustaka ini tersedia dalam bahasa C, Python, dan Perl. 2.3.4 Dependensi Paket Suatu dependensi terjadi ketika suatu paket bergantung pada paket lainnya.  Paket pada sistem Linux bergantung pada paket lainnya. Sebagai contoh kernel  linux bergantung pada paket pustaka C, karena kernel menggunakan file header  yang ada pada paket pustaka C. Atau suatu aplikasi jaringan bergantung pada  pustaka jaringan  low­level.  Meskipun beberapa paket bergantung pada pustaka 

36 sistem, terdapat beberapa paket yang bergantung pada aplikasi yang ada paket  lain. Sebagai contoh editor teks Emacs bergantung pada perl. Program klien basis  data   biasanya   bergantung   pada   aplikasi   server   basis   data.   Basis   data   rpm  menyimpan   informasi   tentang   informasi   dependensi,   jadi   ia   bisa   misalnya  menghentikan penghapusan paket yang masih dibutuhkan paket lain atau memberi  tahu pengguna tentang paket yang dibutuhkan saat instalasi.  Dalam Rpm, setiap paket menyediakan kemampuan­kemampuan yang ia  miliki. Suatu kemampuan hanya kalimat teks sederhana pada file konfigurasi yang  diklaim dimiliki oleh sebuah paket. Paket lain lalu akan bisa bergantung pada  kemampuan ini. Setiap paket mendaftarkan kemampuan yang ia butuhkan dari  paket lain sebagaimana kemampuan yang ia sediakan. Dependensi   paket   dan   kemampuan   sangat   penting   dalam   membuat   file  spec (file konfigurasi rpm) untuk membuat sebuah paket rpm. Ketika suatu paket  diinstal,   informasi   tentang   kemampuan   nya   disimpan   dalam   basis   data   rpm.  Ketika paket dihapus, perintah rpm mengecek basis data rpm. Jika paket yang  dicoba dihapus menyediakan kemampuan yang dibutuhkan paket lain, perintah  akan menghasilkan kesalahan. Pengguna bisa melacak kemampuan yang dibutuhkan sebuah paket dengan  opsi  –requires pada perintah rpm. Dan bisa melihat kemampuan apa yang

37 sebuah paket sediakan dengan opsi –provide.   Dependensi yang kurang lengkap terjadi ketika suatu paket rpm yang telah  terinstal membutuhkan suatu paket yang ternyata belum diinstal hal ini bisa terjadi  ketika pengguna menginstal paket dengan mengabaikan pengecekan dependensi  terlebih dahulu atau suatu berkas yang merupakan bagian dari suatu paket secara  tidak sengaja terhapus sehingga paket ini menjadi paket yang rusak. Akibatnya  paket paket lain yang membutuhkannya tidak dapat berjalan secara normal.  Dependensi suatu paket diketahui oleh rpm dengan membaca header file  yang ada pada berkas paket rpm (*.rpm) . Header ini dihasilkan saat pembuatan  paket rpm dengan mengambil informasi dari berkas spec. 2.3.5 Membuat Paket Rpm Dalam  membangun suatu paket rpm hal pertama  yang harus  dilakukan  adalah membuat direktori BUILD, RPMS, SOURCES, SPECS, dan SRPMS pada  /usr/src/redhat.  Setelah   itu   kode   sumber   aplikasi   yang   akan   dibuat   paket   rpm  diletakkan   pada   direktori   SOURCES.   Langkah   selanjutnya   adalah   membuat  berkas spec, berkas spec adalah berkas spesifikasi yang mendefinisikan semua  aksi yang harus dilakukan saat membangun aplikasi, dependensi yang dibutuhkan,  dan   kemampuan   yang   ia   sertakan.   Berikut   ini   petikan   berkas   spec   untuk  membangun paket kernel­xen.

38 Group: System Environment/Kernel Provides: kernel = %{version} Provides: kernel­%{_target_cpu} = %{rpmversion}­%{release}xen0 Prereq: %{kernel_prereq} Requires: xen Conflicts: %{kernel_dot_org_conflicts} Conflicts: %{package_conflicts} Gambar 2.14 Petikan berkas spec Berkas spec di atas berarti paket kernel­xen menyediakan kemampuan kernel dan  memiliki dependensi terhadap paket xen.  Setelah berkas spec dibuat langkah selanjutnya adalah membuat paket rpm  berdasarkan atas berkas spec yang telah dibuat. Paket rpm yang dihasilkan ada  pada direktori BUILDS. Paket ini berisi berkas aplikasi, dokumentasi, dan pustaka  yang telah dikompilasi serta informasi dimana berkas tersebut harus ditempatkan  dan dependensi yang dibutuhkan yang ada pada berkas header paket (dalam  bentuk biner) tersebut.  

39 2.4 Metodologi Pengembangan Berorientasi Objek Metodologi   pengembangan   yang   berorientasi   objek   adalah   metodologi  yang memfokuskan proses pengembangan terhadap objek objek apa saja yang ada  dalam   sebuah   sistem   yang   dibangun.   Fokus   ini   menyangkut   keberadaan   suatu  objek, hubungannya dengan objek lain, dan tugas serta atribut apa saja yang ia  miliki.  Booch  (Booch, 2001)  membagi proses pengembangan berorientasi objek  menjadi empat aktivitas: 1. Identifikasi Kelas dan Objek Tujuan   dari   pengidentifikasian   ini   adalah   untuk   mengetahui   batasan  masalah yang akan dihadapi. Proses ini dimulai dengan mencari tahu kelas  dan objek apa saja yang akan berperan dalam sistem yang dibangun. Hal  ini bisa dilakukan dengan memverifikasi daftar kata benda yang ada pada  problem domain.  Beberapa kelas dan objek yang berhasil diidentifikasi  pada tahap ini bisa saja salah, tapi ini tidak menjadi masalah.  2. Mengidentifikasi Semantik dari Kelas dan Objek Tujuan   dari   pengidentifikasian   semantik   objek   dan   kelas   adalah   untuk  menentukan perilaku dan atribut dari setiap abstarksi objek dan kelas yang  telah didefinisikan pada langkah sebelumnya. Pada tahap ini untuk setiap 

40 kelas ditentukan atribut atribut apa saja yang ia miliki yang berhubungan  dengan  sistem  dan  menentukan  perilaku   setiap  kelas   tersebut   berkaitan  dengan tugas tugas yang akan ia kerjakan. 3. Mengidentifikasi Hubungan antar Kelas Pada   tahapan   ini   diidentifikasi   bagaimana   seharusnya   hubungan   antara  kelas, hubungan ini meliputi komposisi maupun penurunan(inherintance).  Tujuan dari tahap ini adalah memperkuat batasan dan untuk mengetahui  bagaimana seharusnya masing masing kelas bekerja sama satu sama lain.  4. Implementasi Kelas dan Objek Pada   tahap   ini   dilakukan   penyempurnaan   terhadap   kelas   kelas   yang  berhasil didapatkan sebelumnya. Juga mengenai  relationship  (hubungan)  antar   kelas.   Untuk   dapat   diimplementasikan   pada  class   diagram   (yang  memperlihatkan   semantik   statis)   dan

 activity   diagram   (yang 

memperlihatkan semantik dinamis). 2.5 Unified Modelling Language Unified   Modelling   Language  (UML)   adalah   sebuah   bahasa   yang   telah  menjadi   standar   dalam   industri   untuk   visualisasi,   merancang   dan  mendokumentasikan sistem piranti lunak (Dharwiyanti, 2003). UML menawarkan  sebuah standar untuk merancang model sebuah sistem. 

41 Dalam UML didefinisikan delapan diagram yang digunakan sebagai notasi  saat perancangan yaitu:   use case diagram, sequence diagram, class diagram,   collaboration   diagram,   statechart   diagram,   component   diagram,   activity   diagram,  dan  deployment   diagram.  Pembahasan   mengenai   diagram   UML  selanjutnya   akan  difokuskan   pada   diagram   diagram   yang   akan   digunakan   saat  merancang sistem.   1. Use Case Diagram Use   Case  menggambarkan   fungsionalitas   yang   diharapkan   dari   sebuah  sistem. Sebuah use case merepresentasikan sebuah interaksi antara actor dengan  sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke system,  meng­create sebuah daftar belanja, dan sebagainya.Use case mempunyai beberapa  bagian penting yaitu : Actor, Use Case, dan Relasi 1. Actor  Actor merupakan bagian dari use case yang bertindak sebagai subjek (pelaku)  dalam suatu proses. 2. Use Case  Use Case adalah suatu proses yang terjadi dalam suatu software. Use case juga  menggambarkan apa yang sedang dilakukan oleh Actor 3. Relasi  Relasi menggambarkan hubungan antara actor dengan use case. Relasi­relasi  tersebut dapat dibagi menjadi : ●

Undirectional Association

●

Generalization

42 ●

Dependency

Gambar 2.14 Contoh notasi actor dan use case 2. Class Diagram Class diagram menggambarkan struktur dan deskripsi class, package dan  objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi,  dan lain­lain. Class diagram mempunyai beberapa bagian penting yaitu :  1. Class  Pada UML Class direpresentasikan dalam bentuk segi empat. Nama kelas  dituliskan pada bagian paling atas, daftar atribut pada bagian tengah, dan daftar  metode pada bagian bawah. 

 Gambar 2.15 Contoh notasi class 2. Hubungan Antar Class Antara kelas yang satu dengan kelas yang lain dapat berhubungan dengan  beberapa cara yaitu:  ●

Komposisi, menggambarkan class yang memiliki atribut berupa class lain,  atau class yang harus mengetahui eksistensi class lain. 

●

Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).

●

Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan  dari class lain dan mewarisi semua atribut dan metoda class asalnya dan 

43 menambahkan fungsionalitas baru, sehingga ia disebut anak dari class  yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

Gambar 2.16 Contoh asosiasi antar class

3. Activity Diagram Activity   Diagram  menggambarkan   berbagai   alir   aktivitas   dalam   sistem  yang sedang  dirancang,  bagaimana  masing­masing alir  berawal,  decision  yang  mungkin   terjadi,   dan   bagaimana   mereka   berakhir.   Activity   diagram   ini   mirip  dengan flowchart diagram. Activity diagram juga dapat menggambarkan proses  parallel yang mungkin terjadi pada beberapa eksekusi. Di bawah ini notasi notasi  yang digunakan dalam activity diagram: 1. 

 Merupakan awal dari suatu proses.

2. Merupakan state transition antara satu activity ke activity yang lain. 3. Merupakan notasi yang menggambarkan aktivitas 4.  Merupakan notasi yang menggambarkan keputusan (if then else)

44 5.      Merupakan akhir dari sebuah proses

BAB III ANALISIS DAN RANCANGAN SISTEM 3.1 Analisis Sistem 3.1.1 Use Case Diagram Use case adalah cara yang efektif untuk menangkap kebutuhan fungsional  dari sebuah sistem baru. Setiap use case menyajikan satu atau lebih skenario yang  mendemonstrasikan bagaimana sistem seharusnya berinteraksi dengan pengguna  atau sistem yang lain untuk mencapai suatu tujuan tertentu.  Gambar 3.1 Use Case Diagram 

45 Pada use case di atas pengguna dan waktu adalah aktor yang berperan  dalam sistem. Waktu berfungsi sebagai pembangkit bagi ketiga use case pada  sistem yaitu pemberian saran, pengumpulan paket RPM dengan dependency  kurang lengkap, dan pemantauan kebiasaan user. Pada use case pemberian saran  sistem juga akan berinteraksi dengan pengguna dalam bentuk penampilan saran.  3.1.2 Tipe Agen Awal Analisis mengenai tipe agen yang akan digunakan pada sistem  mendapatkan terdapat tiga agen yang akan berperan: 1. Agen pengumpul paket RPM 2. Agen pemantau kebiasaan pengguna 3. Agen pemberi saran Gambar 3.2 Diagram agen awal Linux

Agen pemantau kebiasaa pengguna

Database RPM

Agen pengumpul paket rpm

Agen pemberi saran

3.1.3 Deskripsi Tugas Agen 

46 Adapun tugas tugas agen yang berhasil didapatkan pada tahap sebelumnya  adalah: 1. Agen pengumpul paket RPM Bertugas mengumpulkan data data tentang paket paket software apa saja  yang memiliki dependency kurang lengkap 2. Agen pemantau kebiasaan user Bertugas mempelajari kebiasaan pengguna yaitu dengan mencatat lama  pemakaian setiap program yang berjalan. 3. Agen pemberi saran Bertugas memberi saran dengan mengambil data data yang dikumpulkan  dua agen sebelumnya. 3.1.4 Hubungan Antar Agen  Pada  sistem ini  agen tidak berinteraksi secara langsung di  mana agen  pengumpul rpm akan menyimpan data yang ia dapatkan pada sebuah  file  begitu  juga agen pemantau kebiasaan user. File­file ini lalu akan dikumpulkan oleh agen  pemberi saran untuk dijadikan dasar dalam pemberian saran kepada pengguna. 3.1.5 Penyempurnaan Agen Pada tahap ini agen agen yang telah diidentifikasi pada tahap 2 tidak  mengalami perubahan.

47 3.1.6 Informasi Deployment Agen Agen yang dibangun akan hidup di atas PC (personal computer) yang  berdiri sendiri (standalone computer). 3.2 Rancangan Sistem 3.2.1 Rancangan Agen   Ketika masalah telah diketahui secara detail melalui analisis, langkah  dilanjutkan pada fase desain, yang bertujuan untuk menspesifikasi solusi.  3.2.1.1 Pembagian/Penggabungan/Penamaan ulang agen Dengan melihat lebih jauh kepada tugas masing masing agen. Diputuskan  untuk menghapus agen pengumpul paket rpm dan menggabungkan dengan agen  pemberi saran. Hal ini dilakukan untuk efisiensi di mana tugas kedua agen ini  sangat berkaitan satu sama lain. Selain itu dilakukan penamaan ulang agen sesuai  dengan tugas masing masing (gambar 3.3). 3.2.1.2 Spesifikasi Interaksi  Interaksi antar agen dilakukan secara tidak langsung melalui file.  ApplicationManagerAgent akan menyimpan hasil pemantauannya tentang  kebiasaan user pada suatu file lalu akan dibaca oleh RL_HNFPAgent. Linux

ApplicationManagerAgent

Database RPM

RL_HNFP Agent

48 Gambar 3.3 Diagram Agen  3.2.1.3 Definisi Protokol Interaksi  ApplicationManagerAgent akan menyimpan hasil pemantauan pada file  ”file/result” sesuai dengan direktori instalasi agen. Data yang disimpan dalam  bentuk struktur data Map dengan kunci (key)nama program yang pernah dipakai  pengguna dan isi map adalah lama pemakaian program. 3.2.1.4 Template Pesan Agen tidak berinteraksi secara langsung dengan saling memberi pesan.  Maka pada sistem ini tidak ada pendefinisian template pesan. 3.2.1.5 Penjelasan untuk Registered/Searched (Yellow Pages) Sistem tidak akan mendaftarkan layanan agen pada Yellow Pages,  sehingga tidak ada pengubahan konvensi nama dan layanan. 3.2.1.6 Interaksi Sumber Daya­Agen  Application manajer agent akan berinteraksi dengan sistem operasi Linux.  di mana agen ini akan mencatat program program apa saja yang dijalankan user  dengan memantau sistem  file  ”/proc”. Sedang RL_HNFPagent akan berinteraksi  dengan   dengan   database   RPM   yang   ada   pada   sistem   operasi   pada   komputer  pengguna. 

49

3.2.1.7 Interaksi Pengguna­Agen  Interaksi antara pengguna dan sistem dilakukan oleh RL_HNFPAgent  dengan menampilkan paket paket software mana saja yang memiliki dependency   kurang lengkap dan memberikan saran apakah software tersebut sebaiknya  didownload atau dihapus saja.  3.2.1.8 Perilaku Internal Agen Adapun deskripsi lengkap perilaku masing masing agen adalah:   1. ApplicationManagerAgent Memantau paket paket software apa saja yang digunakan oleh pengguna.  Hasil pemantauan adalah dalam bentuk lama pemakaian paket paket software  yang telah dipakai pengguna. Informasi yang dikumpulkan akan disimpan  pada file ”file/result”. Agen ini pun bekerja secara periodik yaitu setiap 1  detik mencatat pemakaian software. Sedang hasil pemantauan disimpan setiap  30 menit dan jika komputer dimatikan agen akan terlebih dahulu menyimpan  hasil pemantauan ke dalam file. 2. RL_HNFPAgent Mengambil informasi yang dihasilkan ApplicationManagerAgent,  mengumpulkan informasi paket paket software apa saja yang memiliki 

50 dependency kurang lengkap, menggabungkan dua informasi di atas lalu  memasukkannya pada model RL_HNFP sebagai input, mengambil output  dari model, menampilkan, dan menerima umpan balik dari pengguna. Agen  ini berjalan secara periodik setiap 24 jam. Agen inilah yang memiliki model  RL_HNFP yang digunakan dalam pembelajaran dan pemberian saran. 3.2.1.9 Ontologi Sistem tidak menggunakan ontologi dalam komunikasi antar agen.  3.2.1.10 Bahasa Isi (Content Language) Karena sistem tidak menggunakan ontologi maka bahasa isi (content   language) tidak perlu didefinisikan. 

3.2.2 Rancangan Model Model RL_HNFP yang digunakan pada sistem ini  menggunakan 2 input  dan satu output seperti yang ditunjukkan gambar 3.4.  0,0.1,...1

x1

x2

Select Action

Output

Q

value

51 Gambar 3.4 Arsitektur RL­HNFP Adapun input yang digunakan yaitu: 1. Lamanya   pemakaian   program   yang   mirip   dengan   program   yang  dependencynya kurang. Misal jika program yang  dependencynya kurang  adalah mysql­administrator maka lama pemakaian program yang dijadikan  input salah satunya adalah paket mysql atau paket php­mysql. 2. Lamanya   pemakaian   program   yang   memiliki   grup   yang   sama   dengan  program   yang  dependency  nya   kurang,   misal   untuk   kasus   mysql­ administrator   yang  akan  dijadikan  input  adalah  lama  pemakaian  semua  program yang memiliki grup database. output  yang   akan   dihasilkan   oleh   RL_HNFP   pada   sistem   ini   adalah  bilangan desimal antara 0 dan 1, di mana : 1. Jika output sistem besar atau sama dengan 0.5 maka aksi yang disarankan  adalah mendownload dependency software tersebut.  2. Jika   kurang   dari   0.5   maka   aksi   yang   disarankan   adalah   menghapus  software tersebut. Pada   saat   awal,   RL_HNFP   diinisialisasi   dengan   aksi   aksi   yang   diperbolehkan  yaitu  possibleAction  =   {0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1};   masing   masing  dengan nilai Q=0. 

52 Ganjaran/reward  dihasilkan   dengan   menunggu  feedback  pengguna,  apakah   ia   menerima   saran   tersebut   atau   tidak.   Jika   aksi   adalah   mengunduh  software  maka   saat   pengguna   menyetujui   aksi   tersebut   maka   ganjaran   adalah  sama dengan nilai aksi saat itu. Sebaliknya jika pengguna tidak menyetujui maka  RL_HNFP menerima ganjaran negatif  (1­nilai output).  Jika aksi yang dihasilkan  adalah menghapus software, saat pengguna menyetujui maka ganjarannya adalah  sebesar 1­nilai output. Sebaliknya jika tidak menyetujui maka ganjarannya sama  dengan nilai output. 3.2.3 Rancangan Kelas Kelas   yang   digunakan   dalam   sistem   dirancang   mengikuti   tahapan  pengembangan berorientasi objek pada bab 2.4.     Adapun hasil akhir rancangan  kelas dari sistem yang akan dibangun disajikan dalam diagram UML pada gambar  3.5. Pada  agen class diagram terdapat enam kelas yaitu  1. JRpmAgent   ,   kelas   ini   memiliki   tugas     melakukan   hal   hal   yang  berhubungan   dengan   pengaksesan   basis   data   Rpm   yang   ada   pada  komputer   pengguna,   seperti   mengecek   jenis   grup   dari   suatu   paket  software  , mendapatkan daftar ketergantungan dari suatu paket  software,  dll.

53

Gambar 3.5 Agen Class diagram  2. ApplicationManager, kelas ini bertugas memonitor program program apa  saja   yang   digunakan   pengguna,   juga   bertugas   menyimpan   hasil  pemonitoran tersebut ke dalam sebuah file. 3. ApplicationManagerAgent, adalah kelas yang bertugas sebagai agen untuk  memonitor   program   program   yang   digunakan   pengguna.   Kelas  ApplicationManagerAgent   dalam   melakukan   tugasnya   bekerja   sama  dengan kelas ApplicationManager.

54 4. WiseObject, adalah kelas yang memiliki objek RL_HNFP   yaitu model  RL_HNFP yang   akan memberikan saran dan melakukan pembelajaran  pada sistem ini. Kelas ini juga bertugas mengumpulkan hasil pemonitoran  paket yang dipakai pengguna dan mendapatkan informasi tentang paket  paket   yang   memiliki  dependency  kurang   lengkap.   Mengolah   dan  memasukannya sebagai input pada model RL_HNFP.  5. RL_HNFPAgent   adalah   kelas   yang   bertugas   sebagai   agen   yang   secara  periodik   setiap   24   jam   akan   memberikan   saran   pada   pengguna.   Dalam  melakukan tugasnya kelas ini bekerja sama denga kelas WiseObject. Dalam   pengimplementasian   RL_HNFP   pada   sistem,   model   dibangun  sebagai pustaka yang terpisah dengan sistem agen di atas, hal ini dilakukan untuk  memudahkan pemakaian kembali pustaka RL_HNFP jika suatu saat dibutuhkan.  Karena itu perancangan kelas agen terpisah dengan perancangan kelas RL_HNFP.  Pustaka   RL_HNFP   terdiri   dari   empat   kelas   (gambar   3.6)   yaitu   kelas  RL_HNFP,   kelas   RL_NFPCell,   kelas   Partition,   dan   kelas   FuzzyRule.   Kelas  FuzzyRule   bertugas   menyimpan   aturan   aturan   fuzzy   yang   dibuat   oleh   model.  Kelas ini digunakan oleh kelas partition dalam merepresentasikan aturan aturan  fuzzy yang ia miliki. Kelas partition bertugas merepresentasikan partisi yang ada  pada   model  Reinforcement   Learning   Hierarchical   Neuro   Fuzzy   Politree  (RL­

55 HNFP).   Kelas   RL_HNFP   merepresentasikan   model   RL_HNFP   secara  keseluruhan,   kelas   ini   bertugas   mengambil  input,   menghitung   nilai   keluaran  model secara keseluruhan, dan mengambil nilai ganjaran dari lingkungan. Kelas  RL_NFP adalah kelas yang merepresentasikan satu sel Reinforcement Learning  Neuro Fuzzy Politree (RL_NFP). Kelas ini bertugas menghitung nilai ganjaran  (reward)   beradasarkan   ganjaran   global,   menentukan   apakah   sel   yang  bersangkutan   sudah   harus   berekspansi   atau   tidak,     dan   mengupadate   nilai   Q  berdasarkan nilai ganjaran yang dihasilkan. Kelas RL_HNFP bertugas mengambil  input, menghitung nilai keluaran model secara keseluruhan, dan mengambil nilai  ganjaran dari lingkungan.

Gambar 3.6 RL_HNFP Class Diagram

56

Gambar 3.6 (Lanjutan) 3.2.4 Rancangan Proses Proses   yang   terjadi   dalam   sistem   didefinisikan   secara   lebih   spesifik   dan  digambarkan   dengan   menggunakan   diagram   aktivitas.   Beberapa   proses   yang  terjadi dalam sistem dapat didefinisikan sebagai berikut: 1. Proses pengambilan paket RPM yang kurang lengkap 2. Proses pemonitoran paket 3. Proses pemberian saran 4. Proses penghitungan keluaran pada model RL_HNFP

57 3.2.4.1 Proses pengambilan paket RPM yang kurang lengkap Gambar 3.7 Diagram aktivitas proses pengambilan paket RPM yang kurang  lengkap

Dalam   proses   pengambilan   paket   RPM   yang   kurang   lengkap,   dimulai  dengan pengambilan paket paket pada basis data RPM. Selanjutnya mengecek jika  tidak ada paket yang terinstal maka selesai. Jika tidak maka untuk tiap paket akan  mengecek   apakah  dependency  nya   lengkap   atau   tidak,   jika   tidak   maka   akan  dimasukkan pada daftar lalu disimpan pada file. Proses ini lalu berulang kembali  dengan   mengambil   paket   lain   dari   database   dan   mengecek  dependency  nya.  Sampai semua paket dalam basis data telah dicek semua.

3.2.4.2 Proses pemonitoran paket

58 Proses   pemonitoran   paket   dimulai   dengan   mengecek   program   apa   saja  yang sedang berjalan pada komputer pengguna. Gambar 3.8 Diagram aktivitas proses pemonitoran paket

Lalu setiap program yang berjalan dicatat lama pemakaiannya. Setelah itu  akan terjadi penundaan (delay) selama selang waktu tertentu. Dan proses di atas  akan   diulangi   lagi.   Proses   selesai   saat   agen   berhenti   berjalan.   baik   karena  dimatikan oleh pengguna atau komputer pengguna dimatikan. 3.2.4.3 Proses pemberian saran Pada   proses   pemberian   saran,   sistem   akan   terlebih   dahulu   mengambil  daftar paket dengan dependency yang kurang lengkap. Daftar paket ini  dihasilkan  oleh proses pengambilan paket RPM yang kurang lengkap. Selanjutnya sistem  akan mengambil daftar pemakaian program.  

59 Pada daftar ini terdapat semua paket   beserta   lama pemakaian program.  Untuk setiap paket dengan  dependecy  kurang lengkap akan dibuat daftar paket  yang   mirip   dan   daftar   paket   yang   memiliki   grup   yang   sama     dengan   paket  tersebut. Lalu akan dihitung lama pemakaian setiap program yang ada pada kedua  daftar tersebut. Lama pemakaian program inilah yang akan menjadi masukan bagi  model  RL_HNFP  pada  sistem.  Proses   lalu  dilanjutkan  dengan  menerjemahkan  keluaran model RL_HNFP untuk dapat ditampilkan pada pengguna. 

Gambar 3.9 Diagram aktivitas proses pemberian saran 3.2.4.4 Proses penghitungan keluaran pada model RL_HNFP

60

Gambar 3.10 Diagram aktivitas proses penghitungan keluaran pada model  RL_HNFP Pada   proses   ini   (gambar   2.10)   terlebih   dahulu   diawali   dengan   mengambil  masukan dari pengguna. Selanjutnya untuk tiap tiap sel akan dibuat partisi partisi.  Dari   masing   masing   partisi   ini   akan   dibuat     aturan   aturan   yang   berseuaian  dengannya. Keluaran sel  akan dihitung berdasarkan atas partisi dan aturan yang  telah dibuat. Untuk keperluan pembelajaran maka reward/ganjaran akan diberikan  oleh lingkungan yang akan digunakan untuk memperbaharui nilai Q. Selanjutnya  akan dites kondisi apakah tiap tiap partisi pada sel telah memenuhi syarat untuk 

61 diekspansi jika ya maka partisi akan diekspansi. Dengan membuat sel baru lalu  akan dihubungkan dengan partisi yang bersangkutan. 3.2.5 Rancangan Antar Muka  Sistem agen merupakan sistem yang berjalan secara  autonom.  di  mana  sistem akan berjalan tanpa atau dengan sedikit kontrol dari pengguna. Sistem ini  diusahakan   bisa   memenuhi   kebutuhan   tersebut.   Sistem   ini   dirancang   sehingga  agen   berjalan   saat   komputer   pengguna   dinyalakan.   Artinya   sistem   berjalan  sebagai daemon atau servis yang berjalan di belakang layar  (background process)  Sehingga   pengguna   tidak   perlu   repot   menjalankan   agen   tiap   menyalakan  komputer.   Dan   jika   saat   komputer   pengguna   dimatikan   sedang   agen   masih  berjalan maka agen akan otomatis dimatikan terlebih dahulu dengan menyimpan  hasil pekerjaannya yang belum tersimpan. Selain itu akan disediakan pula skrip  untuk memudahkan pengguna untuk menjalankan dan mematikan jika suatu saat  dibutuhkan.  Karena   agen   berjalan   sebagai   proses  background  maka  output  ataupun  pesan kesalahan tidak akan muncul pada output standar pengguna yang biasanya  merupakan layar monitor. Padahal hal tersebut dibutuhkan untuk melakukan  pengecekan   kesalahan   jika   dibutuhkan.   Untuk   itu   disediakan   juga   mekanisme  penelusuran jejak (logging) yang terdapat pada sebuah file. file ini nantinya akan 

62 dibuat   dengan   kepemilikan  file  yang   memungkinkan   semua   pengguna   pada  komputer kecuali root bisa melihat file tetapi tidak diperbolehkan mengubahnya.  Untuk   antar   muka   penampilan   pesan   kepada   pengguna   maka   akan  digunakan   kotak   dialog.   Ada   dua   macam   dialog   yang   akan   ditampilkan   pada  pengguna. Pertama kotak dialog untuk menampilkan paket paket RPM mana saja  yang dependency nya kurang lengkap. 

Paket ......: Paket ......: OK

Gambar 3.11 Dialog informasi paket Yang kedua  adalah dialog untuk menampilkan saran kepada pengguna.  Dialog ini digunakan oleh sistem untuk menentukan umpan balik dari pengguna,  sesuai dengan saran yang diberikan apakah akan menerima atau tidak. Ada dua  saran yang mungkin tampil ”download dependency” atau ”remove” Download Dependency

Ya

Tidak

Gambar 3.12 Dialog saran download dependency Gambar 3.13 Dialog saran menghapus paket software Remove

Ya

Tidak

63 Ketika pengguna menekan tombol ”ya” saat ini dialog saran  tampil maka  akan tampil dialog konfirmasi apakah pengguna betul betul akan mendownload   dependency dari software tersebut atau menghapus software tersebut. 

Apakah Anda Yakin

Ya

Tidak

Gambar 3.14 Dialog konfirmasi Karena kedua aksi yang akan dilakukan baik itu download dependency ataupun  penghapusan membutuhkan akses root. Maka sebelum perintah tersebut  dilaksanakan maka akan tampil dialog yang meminta password root.

Password:

Ok

Batal

Gambar 3.15 Dialog password

BAB IV IMPLEMENTASI SISTEM

4.1  Pembangunan Sistem

64 Sistem ini dibuat dengan menggunakan bahasa Java dan C. Bahasa Java  digunakakan pada keseluruhan sistem kecuali pada bagian pengaksesan database  RPM. Hal ini dilakukan karena RPM API (antar muka pemrograman untuk rpm)  hanya mendukung bahasa C, C++, dan Python. Sedang dipilihnya bahasa Java  selain     untuk   memudahkan   pembangunan   agen   dengan   banyaknya  framework   agent  yang tersedia juga Java bisa membuat pemrograman lebih efektif, efisien,  serta hasil akan lebih stabil. Antara bahasa C dan Java berkomunikasi dengan  menggunakan JNI (Java Native Interface). 

4.2 Implementasi Agen Menggunakan Reinforcement Learning Hierarchical  Neuro Fuzzy Politree 4.2.1 Kelas FuzzyRule   Kelas  FuzzyRule  bertugas menyimpan aturan aturan fuzzy yang dibuat  oleh model. Kelas FuzzyRule memiliki dua atribut dengan akses private. Artinya  atribut   tersebut   hanya   dapat   diakses   dari   dalam   kelas.   Atribut   tersebut   adalah  antecedent  dan  conclusion.  Berikut   ini   cuplikan   dari   implementasi   kelas  FuzzyRule.  public class FuzzyRule implements Serializable { private double () antecedent; private double conclusion; public String toString(){ String out="if ";

65 for(int i=0; i
Gambar 4.1 Cuplikan kode kelas fuzzy rule Kelas   ini   memiliki   metode   toString   yaitu   untuk   mengkonversi   aturan  aturan   samar   pada   kelas   menjadi   format   kalimat   yang   lebih   mudah   dibaca  manusia (human readable). 4.2.2 Kelas Partition Kelas  partition  adalah kelas yang merepresentasikan partisi pada model  RL_HNFP. Hampir semua proses proses inti pada model terjadi pada kelas ini  seperti proses pembuatan rule antecedent, pembaharuan nilai Q, dan pengecekan  ekspansi   partisi.   Kelas   ini   memiliki   konstruktor   dengan   4   parameter   yaitu  numinput banyaknya input pada partisi yang juga sekaligus banyaknya input pada  RL_HNFP   secara   keseluruhan.  PossibleActions  adalah   aksi   aksi   awal   yang  mungkin terjadi. Qvalues adalah array nilai Q yang berasosiasi dengan aksi aksi  awal   tadi.  Epsilon  adalah   nilai   epsilon   untuk   pembelajaran   pada   proses  Reinforcement   Learning  yang   menggunakan   metode   e­greedy.  Berikut   ini  cuplikan dari implementasi kelas Partition. public Partition(int numinput, double() possibleActions, double() QValues, double epsilon){ this.numOfinput=numinput; this.possibleActions=possibleActions;

66 this.QValues=(double())QValues.clone(); this.epsilon=epsilon; }

Gambar 4.2 Cuplikan kode kelas partition Metode ”chooseAction” adalah metode pada kelas partition yang digunakan untuk  memilih aksi pada partisi yang bersangkutan.  private int chooseAction(){ int selectedAction = -1; double maxQ = -Double.MAX_VALUE; int() doubleValues = new int(QValues.length); int maxDV = 0; if ( Math.random() < epsilon ) { selectedAction = -1;} else { for( int i = 0 ; i < QValues.length ; i++ ) { if( QValues(i) rel="nofollow"> maxQ ) { selectedAction = i; maxQ = QValues(i); maxDV = 0; doubleValues(maxDV) = selectedAction; } else if( QValues(i) == maxQ ) { maxDV++; doubleValues(maxDV) = i; } } if( maxDV > 0 ) { int randomIndex = (int) ( Math.random() * ( maxDV + 1 )); selectedAction = doubleValues( randomIndex ); } }

if ( selectedAction == -1 ) { selectedAction = (int) (Math.random() * QValues.length); }}

Gambar 4.3 Cuplikan metode chooseAction pada kelas partition Metode updateQvalue adalah metode yang bertugas memperbaharui nilai Q untuk  setiap macam aksi yang ada pada partisi berdasarkan atas reward/Ganjaran yang  didapatkan. public void updateQValue(){ if(previousAction == -1)

67 return; if(currentReward>previousReward){ //System.out.println("Good Action"); epsilon-=epsilonLevel; if(epsilon < 0) epsilon=0;

QValues(previousAction)+=(ruleValue*(currentReward+gamma*QValues(action)QValues(previousAction))); } else{ //System.out.println("Bad Action"); epsilon+=epsilonLevel; if(epsilon > 0.1) epsilon=0.1; QValues(previousAction)=(ruleValue*(currentReward+gamma*QValues(action)QValues(previousAction))); } }

Gambar 4.4 Cuplikan metode updateQvalue pada kelas partition 4.2.3 Kelas RL_NFPCell Kelas   RL_NFPCell   adalah   kelas   yang   merepresentasikan   satu   sel   utuh  Reinforcement Learning Neuro Fuzzy Politree. Karena setiap sel ini memiliki 2n  partisi maka setiap objek RL_NFPCell juga memiliki  2n  objek partiton.  public void setinput(double () input) throws IllegalArgumentException{ if(input.length!=numOfinput) throw new IllegalArgumentException("actual input size doesn't match with numberOfinput"); this.input=input; for(int i=0; i
Gambar 4.5 Cuplikan metode setinput pada kelas RL_NFPCell Metode set input adalah metode yang berfungsi mendapatkan input untuk masing  masing sel. input yang masuk ke sel akan diteruskan ke tiap tiap partisi pada sel. public double generateoutput(){ makeRuleAntecedent(); double output=0; double denominator=0; for(int i=0; i<partition.length; i++){ double alfa=1;

68 double () antecedent=partition(i).getRuleAntecedent(); for(int j=0; j
if(result!=0){ output+=alfa*result; denominator+=alfa; } } } return output/denominator; }

Gambar 4.6 Cuplikan metode generateoutput pada kelas RL_NFPCell Metode generateoutput adalah metode yang digunakan oleh kelas ini untuk  menghasilkan nilai output berdasarkan keluaran keluaran yang dihasilkan oleh  partisi partisi yang dimilikinya.  4.2.4 Kelas RL_HNFP Kelas ini merupakan representasi model RL_HNFP secara keseluruhan.   Objek dari kelas ini memiliki satu atau lebih RL_NFPCell. public void setinput(double () input) throws IllegalArgumentException{ rootCell.setinput(input); //generate initial action if(firstTime){ action=rootCell.generateoutput(); firstTime=false; }

69 Gambar 4.7 Cuplikan metode setinput pada kelas RL_HNFP Metode  di  atas   digunakan  untuk  mengambil  input  lalu  akan  dimasukkan  pada  model.  input  yang   masuk   lalu   akan   diteruskan   ke   setiap   RL_NFPCell   yang  dimilikinya. public void learn(double reward){ rootCell.giveReward(reward); double nextAction=rootCell.generateoutput(); rootCell.updateQValue(); rootCell.doPartition(); action=nextAction; }

Gambar 4.8 Cuplikan metode learn pada kelas RL_HNFP Metode learn digunakan oleh kelas ini untuk memberikan ganjaran/reward kepada  model,   Menghitung   keluaran   sel   berikutnya,   memperbaharui   nilai   Q,   dan  melakukan permartisian jika diperlukan. 4.2.5 ApplicationManagerAgent  Kelas   ini   merupakan   implementasi   dari   agen   yang   bertugas   melakukan  pemantauan terhadap aplikasi apa saja yang digunakan oleh pengguna. Agen ini  memiliki   perilaku   dimana   setiap   detik   (1000   ms)   akan   melakukan   pencatatan  program apa saja yang sedang digunakan pengguna. Dan setiap 30 menit akan  menyimpan hasil pencatatannya itu pada sebuah file. Berikut ini cuplikan program  tentang perilaku agen.  super.addBehaviour(new TickerBehaviour(this,1000){ protected void onTick(){ appManager.monitorProcess(); } }

70 ); //save result every 30 minutes super.addBehaviour(new TickerBehaviour(this,30*60*1000){ protected void onTick(){ save(); }

Gambar 4.9 Cuplikan kode perilaku agen ApplicationManagerAgent  Dalam   pemonitoran   program   kelas   ini   mengirimkan   pesan   pada   kelas  ApplicationManager untuk mengeksekusi metode ”monitor process”. Berikut ini  cuplikan program untuk metode ”monitor process” tersebut.  public void monitorProcess(){ file() listFiles = new file("/proc/").listFiles(); for(int i=0; i<listFiles.length; i++){ String name=listFiles(i).getName(); try{ Integer.parseInt(name); if(processName.containsKey(name)){ double oldtime=((Double)processTime.get(name)).doubleValue(); processTime.put(name,Double.valueOf(oldtime+(interval/1000))); } else{ String packetname=readProcessNameFromFile(name); if(!packetname.equals("")){ processName.put(name,packetname); processTime.put(name,Double.valueOf(interval/1000)); } } }

Gambar 4.10 Cuplikan metode monitorProcess

Ketika menyimpan hasil pemonitoran pada file  kelas ini juga mengirimkan pesan  pada kelas ApplicationManager untuk mengeksekusi metode  ”saveResult” .  Berikut ini cuplikan program untuk metode ”saveResult” tersebut.  public void saveResult(String path){ ObjectinputStream input = null;

71 Map name_time=null; if(new file(path).exists()){ try{ input = new ObjectinputStream(new FileinputStream(path)); name_time = (Map)input.readObject(); }catch(FileNotFoundException fe){ fe.printStackTrace(); }catch(IOException ioe){ ioe.printStackTrace(); }catch(ClassNotFoundException cne){ cne.printStackTrace(); }finally{ try{ input.close(); }catch(IOException e){ e.printStackTrace(); } } } else name_time = new HashMap(); Set s=processTime.keySet(); Iterator iter = s.iterator(); while(iter.hasNext()){ Object o = iter.next(); String name=(String)processName.get(o); Double time=(Double)processTime.get(o); if(name_time.containsKey(name)){ Double oldtime=(Double)name_time.get(name); name_time.put(name,Double.valueOf(time.doubleValue()+oldtime.doubleValue( ))); } else name_time.put(name,time); } ObjectoutputStream writer=null; writer = new ObjectoutputStream(new FileoutputStream(path)); writer.writeObject(name_time);

Gambar 4.11 Cuplikan metode saveResult 4.2.6 RL_HNFPAgent Kelas   ini   merupakan   implementasi   dari   agen   yang   bertugas   melakukan  memberikan saran kepada pengguna. Kelas ini setiap dijalankan pertama kali akan 

72 mengecek   kapan   terakhir   kali   dijalankan   jika   telah   lewat   24   jam   maka   akan  menghitung   keluaran   dari   model   untuk   memberikan   saran   kepada   pengguna.  Selain itu jika waktu selama agen ini berjalan telah lebih dari 24 jam, maka agen  juga   akan   memberikan   saran   kepada   pengguna.   Berikut   ini   cuplikan   program  untuk   perilaku   agen   tersebut   dan   cuplikan   program   pencatatan   waktu   kapan  terakhir kali agen memberikan saran kepada pengguna. private void writeLog(){ file file= new file(filename); Calendar cal = Calendar.getInstance(); int hour = cal.get(Calendar.HOUR_OF_DAY); int year=cal.get(Calendar.YEAR); int month=cal.get(Calendar.MONTH); int date=cal.get(Calendar.DAY_OF_MONTH); FileWriter writer=null; try{ writer = new FileWriter(file); writer.write(hour+"-"+date+"-"+month+"-"+year); }catch(Exception e){ e.printStackTrace(); }finally{ try{ writer.close(); }catch(IOException io){ io.printStackTrace(); } } } super.addBehaviour(new WakerBehaviour(this,delay*60*60*1000){ protected void handleElapsedTimeout(){ runAgent(); } } );

Gambar 4.12 Cuplikan metode writeLog private void runAgent(){ jrpmagent.getNotCompletedDependencyPacket(); agent.doAction(); //overwrite log this.writeLog(); }

Gambar 4.13 Cuplikan metode runAgent

73 Kelas ini dalam melakukan aksi di atas bekerja sama dengan kelas JRpmAgent  dengan mengirimkan pesan untuk mengeksekusi metode  getNotCompletedDependencyPacket yang bertugas mengumpulkan paket paket 

software yang memiliki dependency yang memiliki dependency kurang lengkap.  Berikut ini cuplikan metode  getNotCompletedDependencyPacket. public void getNotCompletedDependencyPacket(){ try{ Process proc=null; proc=Runtime.getRuntime().exec("sh script/agent.sh"); proc.waitFor(); }catch(Exception ioe){ ioe.printStackTrace(); } }

Gambar 4.14 Cuplikan metode getNotCompletedDependencyPacket 4.2.7  Dialog Saran  Dalam   menampilkan   saran   kepada   pengguna   agen   menampilkan   kotak   dialog  sederhana sesuai dengan saran yang diberikan. Pada awal pemberian saran agen  menampilkan semua paket  software  yang memiliki  dependency  kurang lengkap  berikut  file  yang hilang. Berikut ini cuplikan kode program untuk menampilkan  dialog tersebut. 

JOptionPane.showMessageDialog(null,jrpmAgent.showAllDependencies( ),"Message From JrpmAgent",JOptionPane.INFORMATION_MESSAGE);

Gambar 4.15 Cuplikan kode untuk menampilkan dialog paket dengan dependency  kurang lengkap beserta dependency yang dibutuhkan

74

Gambar 4.16 Dialog daftar paket beserta file/paket dependency yang hilang Setelah pengguna menekan tombol ”ok” pada dialog di atas maka agen  akan   menampilkan   saran   apakah   sebuah   paket   sebaiknya   didownload  atau  dihapus. Berikut ini kode untuk menampilkan dialog tersebut. if(action rel="nofollow">=0.5){ System.out.println("download dependency"); todo="download dependency of "; reward=action; punishment=1-action; } else{ System.out.println("hapus"); todo="remove "; punishment=action; reward=1-action; }

Gambar 4.17 Kode untuk menampilkan dialog saran Gambar 4.18 Dialog saran hapus paket 

75 Gambar 4.19 Dialog saran download Pemberian saran di atas didasarkan atas keluaran dari model RL_HNFP  yang jika  keluaran besar atau sama dengan 0.5 maka akan menampilkan dialog  download tapi jika kurang dari 0.5 maka akan menampilkan dialog hapus. 4.2.8  Antarmuka Pengguna dengan Sistem Untuk keperluan antar  muka agen dengan pengguna maka  dibuat  skrip  bash   yang   akan   digunakan   pengguna   untuk   menjalankan   dan   memberhentikan  agen. Berikut ini cuplikan skrip bash tersebut.  INSTALLPATH=/home/fuad/workspace/JRpmAgent/Testing export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$INSTALLPATH pidfile=$INSTALLPATH/jrpmagent.pid start(){ nohup echo $$ > $pidfile && cd $INSTALLPATH && exec /usr/java/jdk1.5.0_06/bin/java -classpath $INSTALLPATH/jade.jar:$INSTALLPATH/http.jar:. jade.Boot test1:org.jrpmagent.ApplicationManagerAgent fuad:org.jrpmagent.RL_HNFPAgent > $INSTALLPATH/jrpmagent.log &

Gambar 4.20 Cuplikan skrip bash untuk menjalankan agen stop(){ mypid=`cat $pidfile 2>/dev/null` result=`expr $mypid + 1` kill $result echo "Stop JrpmAgent" } case "$1" in start) start;; stop) stop;; esac exit $?

Gambar 4.21 Cuplikan skrip bash untuk menghentikan agen

76

Gambar 4.22 Keluaran agen ketika agen dijalankan dan dihentikan menggunakan  skrip bash Untuk menjalankan agen menggunakan skrip di atas cukup dengan  mengetikkan nama skrip diikuti dengan parameter start/stop pada terminal.  Contoh penggunaan skrip di atas dapat dilihat pada gambar berikut dengan asumsi  skrip ada pada folder ”/etc/init.d”.   Agar dapat berjalan secara otomatis maka skrip untuk memulai agen perlu  ditambahkan pada file ”.bash_profile” pengguna. Di mana file ini akan otomatis  dieksekusi oleh sistem operasi ketika pengguna login. Berikut ini contoh  ”bash_profile” yang telah dimodifikasi. # .bash_profile # Get the aliases and functions if ( -f ~/.bashrc ); then . ~/.bashrc fi # User specific environment and startup programs

77 LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib:/usr/local/kaffe/jre/lib/ i386 JAVA_HOME=/usr/java/jdk1.5.0_06/ PATH=/usr/bin:/home/fuad/:/bin:/usr/j2me/bin/:/usr/local/bin/:$HOME/bin: export LD_LIBRARY_PATH export JAVA_HOME export PATH /etc/init.d/jrpmagent start

Gambar 4.23 Contoh file bash_profile yang ditambahkan skrip untuk menjalankan  agen Pada file di atas agar dapat berjalan otomatis maka pada akhir file  ”.bash_profile” ditambahkan skrip untuk menjalankan agen yaitu perintah  ”/etc/init.d/jrpmagent start”   Berkas logging (penelusuran jejak) ada pada berkas jrpmagent.log yang  ada pada direktori instalasi. Berikut ini cuplikan file log yang ada pada file  tersebut.

delay =10 1 init 2 ksoftirqd/0 3 watchdog/0 4 events/0 5 khelper 6 kthread 8 kblockd/0 9 kacpid 91 khubd 146 pdflush 147 pdflush 314 kpsmoused 330 kjournald 369 kauditd 393 udevd

78 681 kgameportd 1097 kmirrord 1120 kjournald 1122 kjournald 1407 mdmpd 1419 dbus­daemon 1506 automount 1519 acpid 1554 xfs 1571 hald

Gambar 4.24 Contoh file log agen pada jrpmagent.log file  di atas berarti agen akan memberikan saran kepada pengguna 10 jam lagi  sedang baris baris yang ada di bawahnya merupakan daftar program yang sedang  dijalankan pengguna.

BAB V PENGUJIAN DAN HASIL 5.1 Pengujian Sistem  Untuk   menguji   sistem   maka   akan   sengaja   diinstall   paket   Rpm   yang  memiliki  dependency  kurang lengkap.   Sebagai contoh pada pengujian ini akan  diinstal secara paksa paket clamav dan pgadmin. 

79 Saat akan diinstal dengan normal paket clamav dan pgadmin mengalami  error saat instalasi karena adanya  dependency yang tidak terpenuhi. Dibawah ini  ditampilkan keluaran dari sistem ketika akan menginstal kedua paket ini. (fuad@fuad linuxmaster)$ sudo rpm ­ivh clamav­0.88­2.fc5.i386.rpm Password: warning: clamav­0.88­2.fc5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 error: Failed dependencies:         clamav­lib = 0.88­2.fc5 is needed by clamav­0.88­2.fc5.i386         data(clamav) is needed by clamav­0.88­2.fc5.i386         libclamav.so.1 is needed by clamav­0.88­2.fc5.i386 (fuad@fuad potgresql)$ sudo rpm ­ivh pgadmin3­1.4.1­1hjh.i586.rpm Password: error: Failed dependencies:         wxGTK2.6 is needed by pgadmin3­1.4.1­1hjh.i586         libwxgtk2.6 is needed by pgadmin3­1.4.1­1hjh.i586         libcrypto.so.0.9.7 is needed by pgadmin3­1.4.1­1hjh.i586         libpq.so.3 is needed by pgadmin3­1.4.1­1hjh.i586         libssl.so.0.9.7 is needed by pgadmin3­1.4.1­1hjh.i586         libwx_baseu­2.6.so.0 is needed by pgadmin3­1.4.1­1hjh.i586         libwx_gtk2u_core­2.6.so.0 is needed by pgadmin3­1.4.1­1hjh.i586         libwx_gtk2u_html­2.6.so.0 is needed by pgadmin3­1.4.1­1hjh.i586         libwx_gtk2u_ogl­2.6.so.0 is needed by pgadmin3­1.4.1­1hjh.i586         libwx_gtk2u_qa­2.6.so.0 is needed by pgadmin3­1.4.1­1hjh.i586         libwx_gtk2u_stc­2.6.so.0 is needed by pgadmin3­1.4.1­1hjh.i586

Gambar 5.1 Keluaran Linux ketika clamav dan pgadmin hendak diinstal  Untuk   itu   keduanya   dipaksa   diinstal   dengan   tanpa   melakukan   pengecekan  dependency. (fuad@fuad linuxmaster)$ sudo rpm ­ivh ­­nodeps clamav­0.88­2.fc5.i386.rpm warning: clamav­0.88­2.fc5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1ac70ce6 Preparing...                ########################################### (100%)    1:clamav                 ########################################### (100%) (fuad@fuad linuxmaster)$ sudo rpm ­ivh ­­nodeps pgadmin3­1.4.1­1hjh.i586.rpm warning: pgadmin3­1.4.1­1hjh.i586.rpm: Header V3 DSA signature: NOKEY, key ID bhg70gj9 Preparing...                ########################################### (100%)    1:pgadmin3              ########################################### (100%)

80 Gambar 5.2 Keluaran Linux ketika clamav dan pgadmin hendak diinstal secara  paksa tanpa melakukan pengecekan dependency Dengan demikian clamav dan pgadmin3 tidak dapat  dijalankan karena  adanya  dependency yang kurang lengkap.   Selanjutnya   tinggal   menunggu   saran   yang   akan   diberikan   agen.   Untuk  mengecek apakah agen berjalan atau tidak pengguna bisa melihat pada file jejak  yang ada pada file jrpmagent.log. (fuad@fuad Testing)$ cat jrpmagent.log create new model delay =10 1 init 2 ksoftirqd/0 3 watchdog/0 4 events/0 5 khelper 6 kthread 8 kblockd/0 9 kacpid 91 khubd 146 pdflush

Gambar 5.3 Contoh file log agen 

File  di atas berarti agen akan membuat model RL_HNFP baru dan akan  terdapat   jeda   waktu   10   jam   sebelum   agen   memberikan   saran   pada   pengguna.  Selanjutnya pengguna bisa menggunakan komputer seperti biasa karena proses  proses yang dilakukan agen bekerja di belakang layar (background process).  Setelah   10   jam   berlalu   maka   agen   akan    memberikan   saran   kepada  pengguna mengenai paket paket Rpm mana saja yang dependency nya kurang 

81 lengkap   dan   memberikan   saran   apakah   paket   tersebut   sebaiknya   dihapus   atau  tidak. Berikut ini keluaran yang dihasilkan agen:

Gambar 5.4 Dialog awal agen Pada pesan awal agen akan memberi tahu paket software mana saja yang  memiliki  dependency  kurang   lengkap   berikut   paket   dan   atau  file  yang  dibutuhkannya. Untuk clamav paket yang ia butuhkan adalah clamav­lib dengan  versi   0.88­2,   data(clamav),   dan  file  libclamav.so.1.   Sedang   pgadmin  membutuhkan   paket   wxGTK2.6,  file  libwxgtk2.6,  file  libcrypto.so.0.9.7,  file  libpq.so.3,  file  libssl.so.0.9.7,   libwx_baseu­2.6.so.0,   libwx_baseu_net­2.6.so.0,  libwx_baseu_xml­2.6.so.0, libwx_gtk2u_adv­2.6.so.0, libwx_gtk2u_core­2.6.so.0 

82 , libwx_gtk2u_html­2.6.so.0, libwx_gtk2u_ogl­2.6.so.0, libwx_gtk2u_qa­2.6.so.0  , libwx_gtk2u_stc­2.6.so.0, dan libwx_gtk2u_xrc­2.6.so.0. Untuk menghasilkan  saran agen membutuhkan dua data masukan yaitu  lama pemakaian program dengan grup yang sama dan lama pemakaian program  yang namanya mirip. Untuk clamav masuk ke dalam grup   “Applications”   dan  “file” sedang pgadmin3 ada pada grup database. Dari  file  jejak agen didapatkan  keluaran lama pemakaian grup clamav dan pgadmin3 adalah  3576.350000000092  dan 1005.57 ms. Sedang lama pemakaian program yang mirip keduanya adalah 0  ms.   Kedua   angka   ini   lalu   akan   diinputkan   pada   model   RL_HNFP   untuk  menghitung keluaran agen. Saat menerima input model RL_HNFP lalu akan membentuk aturan aturan  yang   akan   digunakan   dalam   penghitungan   keluaran.   Dalam   proses   ini   model  terlebih dahulu membuat antesenden aturan yang kemudian akan dihitung nilainya  berdasarkan fungsi keanggotaan  high  dan  low (gambar 2.6), adapun antesenden  aturan model ini adalah:  if input0 is low and input1 is low  if input0 is low and input1 is high  if input0 is high and input1 is low  if input0 is high and input1 is high 

Gambar 5.5 Contoh antesenden model

83 dimana input0 adalah lama pemakaian paket yang mirip dan input1 adalah lama  pemakaian grup. Adapun perhitungan manual nilai fungsi keanggotaan setelah diberi input  adalah: 1. Untuk paket clamav  low(lama pemakaian paket mirip) = low(0.0/1000)= 0.8807970779778824 high(lama pemakaian paket mirip) = high(0.0/1000)= 0.11920292202211757 low(lama pemakaian grup) = low(3576.350000000092/1000) = 0.7832538513355671 high(lama pemakaian grup)= high(3576.350000000092/1000) = 0.2167461486644328

Gambar 5.6 Perhitungan manual fungsi keanggotaan untuk paket clamav

2. Untuk paket pagadmin3  low(lama pemakaian paket mirip) = low(0.0/1000) = 0.8807970779778824 high(lama pemakaian paket mirip) = high(0.0/1000) = 0.11920292202211757 low(lama pemakaian grup) = low(1005.57/1000) = 0.8580132745028799 high(lama pemakaian grup) = high(1005.57/1000) =0.14198672549712016

Gambar 5.7 Perhitungan manual fungsi keanggotaan untuk paket pgadmin Setelah nilai antesenden didapatkan selanjutnya adalah memilih aksi untuk  tiap tiap aturan yang diwakili oleh partisi. Aksi dipilih dengan melihat nilai Q  yang   paling   baik.   Masing   masing   nilai   Q   mewakili   kemungkinan   aksi   yang 

84 diperbolehkan

 {0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1}.

 Berikut   ini   hasil 

penghitungan agen dalam pemilihan aksi:   1. Pemilihan aksi untuk paket clamav nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.01925363328724654 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 partition 0 select action 0.4 nilai Q 0.0 nilai Q 0.0 nilai Q ­0.0015347664246158396 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.08054828492441687

Gambar 5.8 Keluaran agen pada file jejak (jrpmagent.log) dalam pemilihan aksi  untuk paket clamav

nilai Q 0.0 nilai Q 0.0 nilai Q ­0.0020014792193703513 nilai Q 0.0 partition 1 select action 0.6 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.24548209776488158 nilai Q ­0.006850960874515635 nilai Q 0.0 nilai Q ­0.04833513160279738 nilai Q ­0.034768265056698916 nilai Q 0.0 nilai Q 0.014363596963369871 nilai Q 0.0 partition 2 select action 0.3 nilai Q ­0.08527643749576384

85 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 1.6635114267981723 nilai Q 0.0 partition 3 select action 0.9

Gambar 5.8 (Lanjutan)

2. Pemilihan aksi untuk paket pgadmin nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.01925363328724654 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0

Gambar 5.9 Keluaran agen pada file jejak (jrpmagent.log) dalam pemilihan aksi  untuk paket pgadmin nilai Q 0.0 Exploring ... partition 0 select action 1.0 nilai Q 0.0 nilai Q 0.0 nilai Q ­0.0015347664246158396 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.08054828492441687 nilai Q 0.0 nilai Q 0.0 nilai Q ­0.0020014792193703513 nilai Q 0.0 partition 1 select action 0.6 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 1.3116675090684216 nilai Q ­0.006850960874515635

86 nilai Q 0.0 nilai Q ­0.04833513160279738 nilai Q ­0.034768265056698916 nilai Q 0.0 nilai Q 0.014363596963369871 nilai Q 0.0 Exploring ... partition 2 select action 0.3 nilai Q ­0.08527643749576384 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.0 nilai Q 0.4014133827973537 nilai Q 0.7263539425712009 nilai Q 0.0 partition 3 select action 0.9

Gambar 5.9 (Lanjutan) Dengan demikian aturan aturan saat menangani clamav menjadi  if input0 is low and input1 is low then output=0.4 if input0 is low and input1 is high then output=0.6 if input0 is high and input1 is low then output=0.3 if input0 is high and input1 is high then output=0.9

Gambar 5.10 Aturan lengkap yang dihasilkan agen ketika menangani clamav Sedang pada saat mengani pgadmin adalah if input0 is low and input1 is low then output=1.0 if input0 is low and input1 is high then output=0.6 if input0 is high and input1 is low then output=0.3 if input0 is high and input1 is high then output=0.9

Gambar 5.11 Aturan lengkap yang dihasilkan agen ketika menangani pgadmin Karena model saat ini hanya terdiri atas satu sel saja, belum mengalami  ekspansi maka keluaran model dapat langsung dihitung menggunakan persamaan  4 pada gambar 2.11. Berikut ini perhitungan manual keluaran akhir agen:

87 alfa0 =low(lama pemakaian paket mirip)*low(lama pemakaian grup) =0.8807970779778824*0.7832538513355671=0.68988764 alfa1 =low(lama pemakaian paket mirip)*high(lama pemakaian grup) =0.8807970779778824*0.2167461486644328=0.1909093 alfa2= high(lama pemakaian paket mirip)*low(lama pemakaian grup) =0.11920292202211757*0.7832538513355671=0.093366 alfa3= high(lama pemakaian paket mirip)*high(lama pemakaian grup) =0.11920292202211757*0.2167461486644328=0.02583677 0.68988764*0.4+0.1909093*0.6+0.093366*0.3 output=

+0.0258

3677*0.9

0.68988764+ 0.1909093+ 0.093366 +

0.02583677

Gambar 5.12 Perhitungan manual keluaran agen untuk paket clamav Adapun   keluaran   sistem   adalah   sebesar   0.44176   yang   berarti   harusnya   akan  menampilkan   saran   penghapusan   paket.   Untuk   kasus   pgadmin   perhitungan  manual yang dilakukan adalah sebagai berikut: 

alfa0 =low(lama pemakaian paket mirip)*low(lama pemakaian grup) =0.8807970779778824*0.8580132745028799=0.755735585045 alfa1 =low(lama pemakaian paket mirip)*high(lama pemakaian grup) =0.8807970779778824*0.14198672549712016=0.112506149 alfa2= high(lama pemakaian paket mirip)*low(lama pemakaian grup) =0.11920292202211757*0.8580132745028799=0.102277 alfa3= high(lama pemakaian paket mirip)*high(lama pemakaian grup) =0.11920292202211757*0.14198672549712016=0.016925232556

0.755735585045*1.0+0.112506149*0.6 output=

+0.102277*0.3+0.016925232556*0.9 0.755735585045+0.112506149+0.102277+ 0.016925232

88 output=

0.5146

Gambar 5.13 Perhitungan manual keluaran agen untuk paket pgadmin Dari perhitungan di atas didapatkan bahwa untuk kasus pgadmin keluaran sistem  adalah 0.5146 yang berarti agen seharusnya akan memberikan saran  download  kepada pengguna.  5.2 Hasil Pengujian Untuk mengetahui apakah sistem yang telah dibuat berjalan dengan baik  maka hasil perhitungan manual di atas akan dicocokkan dengan saran nyata yang  menjadi keluaran agen. Berikut ini saran yang diberikan agen untuk paket clamav  dan pgadmin. 

Gambar 5.14 Dialog saran clamav Gambar 5.15 Dialog saran pgadmin

89 Dari hasil pengecekan di atas didapatkan bahwa saran yang diberikan agen  telah sesuai dengan perhitungan manual yang didapatkan sebelumnya, sehingga  dapat disimpulkan bahwa agen yang telah dapat menerapkan model reinforcement   learning hierarchical neuro fuzzy politree  dengan menghasilkan keluaran yang  sesuai dengan harapan.

BAB VI PENUTUP 6.1 Kesimpulan Sistem yang dibangun mempunyai beberapa kemampuan dan kekurangan.  Berikut  kesimpulan  dari  sistem  agen  yang  menggunakan  model  reinforcement   learning hierarchical neuro fuzzy politree.

90 1. Agen   dapat   memberikan   saran   tentang   paket   rpm   dengan  dependency  kurang   lengkap   apakah   harus   mendownload   kekurangan   paket   tersebut  atau   sebaiknya   dihapus   saja.   Dimana   saran   diambil   dengan   melihat  kebiasaan pengguna dalam menggunakan aplikasi. 2. Agen berjalan sebagai  daemon  dan hanya tampil saat memberikan saran,  sehingga pengguna dimudahkan dengan tidak perlu repot menjalankan dan  menghentikan agen.  3. Agen dapat menerapkan model reinforcement learning hierarchical neuro   fuzzy   politree,  sehingga   agen   dapat   menghasilkan   pengetahuan   secara  mandiri   dengan   memanfaatkan   pengalaman   selama   agen   berjalan   tanpa  membutuhkan pengetahuan awal.

6.2 Saran Saran yang diberikan untuk pengembangan sistem selanjutnya adalah : 1. Agen   hendaknya   dapat   juga   dijalankan   pada   distro   yang   tidak  menggunakan   paket   manajer   rpm   atau   pada   distro   yang   tidak  menggunakan paket manajer. 2. Agen   sebaiknya   dapat   berjalan   pada   lingkungan   komputer   yang  terhubung dengan jaringan, dimana agen bisa sekaligus mengecek dan 

91 memberikan saran pada komputer komputer yang terhubung melalui  jaringan tersebut. 3. Model    reinforcement   learning   hierarchical   neuro   fuzzy   politree   sebaiknya   diuji   pada   lingkungan   yang   lebih   kompleks,   seperti   pada  jaringan internet atau pada data mining untuk menguji efektifitas dan  validitas model