- Dendral : Mengidentifikasi struktur organik tak dikenal melalui analisa spektrum massa dan ilmu kimia
- Mycin: Identifikasi bakteri penyebab infeksi dan merekomendasikan antiobiotik dengan dosis yang disesuaikan dengan berat tubuh pasien. Dirancang oleh Edward Feigenbaum (Universitas Stanford) th ’70 an.
- Dipmeter Advisor: Digunakan oleh Schlumberger untuk analisis data dalam pengeboran minyak.
- XCON & XSEL : Membantu konfigurasi sistem komputer besar. Dikembangkan oleh Digital Equipment Corporation (DEC) dan Carnegie Mellon Universitas (CMU), akhir ’70 an. Untuk sistem komputer DEC VAC 11 1780
- Sophie : Analisis sirkit elektronik
- Prospector : Digunakan di dalam geologi untuk membantu mencari dan menemukan deposit. Didesign oleh Sheffield Research Institute, akhir ‘70an
- Folio : Menbantu memberikan keutusan bagi seorang manajer dalam hal stok broker dan investasi.
- Delta : Pemeliharaan lokomotif listrik disel. Didesign & dikembangkan oleh General Electric Company.
- YESMVS : Membantu operator komputer & mengontrol sistem operasi MVS (multiple virtual storage). Didesign oleh IBM awal th ‘80an
- ACE : SP troubleshooting pd sistem kabel telpon. Didesign & dikembangkan oleh AT&T Bell Lab awal th ‘80an
Sabtu, 05 Maret 2011
Contoh Aplikasi dan Pengembangannya (Contoh) Sistem Pakar
09.06
No comments
Contoh Aplikasi Sistem Pakar
Aplikasi Sederhana: Sistem Pakar Bengkel Mobil
Ini
adalah contoh Sistem Pakar sederhana, yang bertujuan untuk mencari apa
yang salah sehingga mesin mobil pelanggan yang tidak mau hidup, dengan
memberikan gejala-gejala yang teramati. Anggap Sistem Pakar kita
memiliki aturan-aturan berikut:
1. JIKA mesin_mendapatkan_bensin DAN starter_dapat_dihidupkan MAKA ada_masalah_dengan_pengapian
2. JIKA TIDAK BENAR starter_dapat_dihidupkan DAN TIDAK BENAR lampu_menyala MAKA ada_masalah_dengan_aki
3. JIKA TIDAK BENAR starter_dapat_dihidupkan DAN lampu_menyala MAKA ada_masalah_dengan_starter
4. JIKA ada_bensin_dalam_tangki_bahan_bakar MAKA mesin_mendapatkan_bensin
Terdapat
3 masalah yang mungkin, yaitu: ada_ masalah_ dengan _pengapian, ada_
masalah_ dengan_ aki dan ada_ masalah_ dengan_ starter. Dengan sistem terarah-tujuan (goal-driven), kita hendak membuktikan keberadaan setiap masalah tadi.
Pertama,
Sistem Pakar berusaha untuk membuktikan kebenaran
ada_masalah_dengan_pengapian. Di sini, aturan 1 dapat digunakan,
sehingga Sistem Pakar akan menset goal baru untuk membuktikan apakah
mesin_mendapatkan_bensin serta starter_dapat_dihidupkan. Untuk
membuktikannya, aturan 4 dapat digunakan, dengan goal baru untuk
membuktikan mesin_mendapatkan_bensin. Karena tidak ada aturan lain yang
dapat digunakan menyimpulkannya, sedangkan sistem belum memperoleh
solusinya, maka Sistem Pakar kemudian bertanya kepada pelanggan: “Apakah
ada bensin dalam tangki bahan bakar?”. Sekarang, katakanlah jawaban
klien adalah “Ya”, jawaban ini kemudian dicatat, sehingga klien tidak
akan ditanyai lagi dengan pertanyaan yang sama.
Nah,
karena sistem sekarang sudah dapat membuktikan bahwa mesin mendapatkan
bensin, maka sistem sekarang berusaha mengetahui apakah
starter_dapat_dihidupkan. Karena sistem belum tahu mengenai hal ini,
sementara tidak ada aturan lagi yang dapat menyimpulkannya, maka Sistem
Pakar bertanya lagi ke klien: “Apakah starter dapat dihidupkan?”.
Misalkan jawabannya adalah “Tidak”, maka tidak ada lagi aturan yang
dapat membuktikan ada_masalah_dengan_pengapian, sehingga Sistem Pakar
berkesimpulan bahwa hal ini bukanlah solusi dari problem yang ada, dan
kemudian melihat hipotesis berikutnya: ada_masalah_dengan_aki. Sudah
diketahui (dibuktikan) bahwa mesin tidak dapat distarter, sehingga yang
harus dibuktikan adalah bahwa lampu tidak menyala. Sistem Pakar kemudian
bertanya: “Apakah lampu menyala?”. Misalkan jawabannya adalah “Tidak”,
maka sudah terbukti bahwa ada masalah dengan aki.
Sistem
ini mungkin berhenti sampai di sini, tetapi biasanya ada kemungkinan
terdapat lebih dari satu solusi (misalnya terdapat lebih dari satu
kerusakan), atau ada kemungkinan terdapat solusi lain yng lebih tepat,
sehingga biasanya semua hipotesis diperiksa kebenarannya. Sistem Pakar
ini kemudian mencoba membuktikan bahwa ada_masalah_dengan_starter, namun
dari fakta yang sudah diperoleh, yaitu lampu tidak menyala, maka
pembuktiannya menjadi gagal. Dengan demikian solusi yang diberikan oleh
Sistem Pakar adalah ada masalah dengan aki.
Secara lengkap, interaksi antara Sistem Pakar dengan klien mungkin seperti ini:
System Pakar: Apakah ada bensin dalam tangki bahan bakar?
Klien: Ya
System Pakar: Apakah starter dapat dihidupkan?
Klien: Tidak
System Pakar: Apakah lampu menyala?
Klien: Tidak
System Pakar: Saya berkesimpulan bahwa ada masalah dengan aki
Fasilitas Penjelasan
Kebanyakan
Sistem Pakar mempunyai fasilitas penjelasan yang mengijinkan klien
untuk bertanya mengapa dia diberi suatu pertanyaan atau bagaimana dapat
mencapai suatu kesimpulan. Pertanyaan dari klien tersebut dijawab dengan
mengacu pada goal, aturan yang dipakai, dan data-data yang ada. Contoh pemakaian fasilitas penjelas dalam Sistem Pakar di atas dapat dilihat pada percakapan berikut:
System Pakar: Apakah ada bensin dalam tangki bahan bakar?
Klien: Ya
System Pakar: Apakah starter dapat dihidupkan?
Klien: Tidak
System Pakar: Apakah lampu menyala?
Klien: Mengapa?
System
Pakar: Saya mencoba membuktikan bahwa ada masalah dengan aki. Sudah
ditunjukkan adalah tidak benar starter dapat dihidupkan. Sehingga jika
tidak benar bahwa lampu menyala, maka ada masalah dengan aki. Apakah
lampu menyala?
Klien: Tidak
System Pakar: Saya berkesimpulan bahwa ada masalah dengan aki
Klien: Bagaimana bisa?
System
Pakar: Hal ini sesuai dengan aturan no 2: JIKA TIDAK BENAR
starter_dapat_dihidupkan DAN TIDAK BENAR lampu_menyala MAKA
ada_masalah_dengan_aki bahwa tidak benar starter_dapat_dihidupkan sudah
dijawab, bahwa tidak benar lampu_menyala sudah dijawab, sehingga dapat
disimpulkan bahwa ada_masalah_dengan_aki.
Fasilitas
penjelasan berhubungan dengan pencatatan aturan apa saja yang digunakan
untuk mengambil kesimpulan, dan menggunakan catatan tersebut untuk
menyusun penjelasan. Pembangkitan penjelasan sederhana seperti contoh di
atas bukanlah persoalan yang sulit, namun pemahaman klien terhadap
penjelasan tersebut tidaklah sama, sehingga seringkali klien tetap tidak
mengerti maksudnya. Hal ini karena biasanya penjelasan hanya meliputi
pengetahuan yang dangkal atau hanya permukaan saja sebagaimana tercantum
dalam autran yang dipunyai, bukannya pengetahuan yang mendalam yang
mendasari aturan tersebut. Dalam contoh di atas, Sistem Pakar hanya
mengatakan bahwa hal ini sesuai dengan aturan no 2, tetapi tidak
menjelaskan secara lebih detil mengenai aturan 2 tersebut. Mungkin klien
perlu diberi pengertian bahwa lampu dan starter dua-duanya menggunakan
aki untuk menyalakannya. Hal penting lain adalah ketika klien gagal
mengerti atau menerima penjelasan yang diberikan, biasanya Sistem Pakar
tidak dapat memberi penjelasan dengan cara lain (tidak begitu halnya
dengan seorang pakar yang mampu menggunakan kalimat yang lain untuk
mencoba menjelaskannya).
2. Eliza
Eliza
adalah salah satu Sistem Pakar yang paling awal dikembangkan. Ini
adalah program komputer terapis yang dibuat oleh Joseph Weizenbaum di
MIT. Pengguna berkomunikasi dengannya sebagaimana sedang berkonsultasi
dengan seorang terapis. Berikut ini adalah contoh percakapan antara
Eliza dengan seorang klien:
Eliza: Hello. I am ELIZA. How can I help you?
Klien: My name is Balza.
Eliza: I have told you before, I do not care about names.
Klien: I don’t have any money. That’s my problem.
Eliza: Why do you say your problem?
Klien: Because you asked me.
Eliza: Do any other reasons not come to mind?
Klien: No.
Eliza: You are being a bit negative.
Klien: Why?
Eliza: Please go on.
Klien: OK. I am bankrupt.
Eliza: How long have you been bankrupt?
Klien: A year.
Eliza: Please go on.
Klien: So, what should I do?
Eliza: Does that question interest you?
Klien: Yes, how can I make big money?
Eliza: You are sure?
Klien: Of course I’m sure.
...
3. Parry
Parry adalah Sistem Pakar yang juga paling awal dikembangkan di Stanford University
oleh seorang psikiater, Kenneth Colby, yang mensimulasikan seorang
paranoid. Berikut ini contoh respon Parry terhadap pertanyaan seorang
psikiater yang menginterviunya.
Psikiater: Why are you in the hospital?
Parry: I shouldn't be here.
Psikiater: Who brought you here?
Parry: The police.
Psikiater: What trouble did you have with the police?
Parry: Cops don't do their job.
Psikiater: What do they do instead?
Parry: Cops arrest the wrong people.
Psikiater: They arrest the right ones sometimes
Parry: The law should get those Italian crooks.
Psikiater: Are you Italian?
Parry: My background is British but I was born in this country.
Psikiater: Do you know any Italian crooks?
Parry: I try to avoid the underworld....
Contoh Tampilan
Sumber:
Rabu, 02 Maret 2011
Pemrograman Berorientasi Objek
08.58
No comments
Pemrograman berorientasi objek (Inggris:
object-oriented programming disingkat OOP) merupakan paradigma
pemrograman yang berorientasikan kepada objek. Semua data dan fungsi di
dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek.
Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat
menerima pesan, memproses data, dan mengirim pesan ke objek lainnya.
II Konsep Pemrograman Berorientasi Obyek
Hidup di dunia terdiri dari banyak objek. Objek ini berada disekitar, bisa dibuat, dipakai dalam bisnis dan dalam produk yang kita gunakan. Objek ini bisa dikategorikan, digambarkan, dimanipulasi dan dibuat. Oleh karena itu bukanlah suatu hal yang baru, bahwa pandangan yang berorientasi objek diusulkan untuk pengembangan perangkat lunak komputer.
II Konsep Pemrograman Berorientasi Obyek
Hidup di dunia terdiri dari banyak objek. Objek ini berada disekitar, bisa dibuat, dipakai dalam bisnis dan dalam produk yang kita gunakan. Objek ini bisa dikategorikan, digambarkan, dimanipulasi dan dibuat. Oleh karena itu bukanlah suatu hal yang baru, bahwa pandangan yang berorientasi objek diusulkan untuk pengembangan perangkat lunak komputer.
Langganan:
Komentar (Atom)













