BAB III ANALISIS DAN PERANCANGAN SISTEM

Transkripsi

1 BAB III ANALISIS DAN PERANCANGAN SISTEM 3.1 Analisis Sistem Analisis sistem merupakan bagian yang sangat penting, karena apabila terjadi kesalahan dalam tahap ini, maka akan mengakibatkan kesalahan pada tahap selanjutnya. Pada bagian analisis sistem ini akan dibahas tentang analisis masalah, analisis sistem yang sedang berjalan, analisis sistem yang dikembangkan, analisis sumber pengetahuan, analisis penyakit dan gejala, analisis non fungsional, analisis basis data dan analisis kebutuhan fungsional Analisis Masalah Analisis masalah adalah penguraian dari suatu masalah yang utuh kedalam bagian-bagian komponennya dengan maksud mengidentifikasi dan mengevaluasi permasalahan, kesempatan,hambatan yang terjadi dan kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan. Kurangnya pengetahuan yang cukup dalam penanganan kerusakan mobil secara umum melanda hampir semua pemilik mobil. Hal ini mengakibatkan sebagian besar masyarakat umum atau suatu institusi tidak dapat mengidentifikasi letak kerusakan yang terjadi pada komponen mobilnya. Sehingga banyak sekali pemilik mobil yang mengeluarkan biaya yang cukup besar untuk memperbaiki kerusakan yang terjadi pada komponen mobilnya tersebut kepada ahli/pakar troubelshooting otomotif. Itu pun belum tentu kerusakan yang terjadi pada koponen yang lebih besar lagi atau yang lebih berat yang tidak dapat diperbaiki sendiri. 48

2 49 Dalam hal komunikasi pun terdapat kesulitan antara masyarakat dengan pakar service komponen mobil secara umum. Kebanyakan disebabkan karena kurangnya pengetahuan yang cukup tentang dunia otomotif atau komponen mobil itu sendiri, sehingga mereka mengalami kesulitan dalam mengutarakan letak permasalahan yang terjadi pada komponen mobilnya. Berdasarkan analisis masalah di atas, maka melalui tugas akhir ini dibuat alternatif penyajian informasi dan konsultasi tentang kerusakan yang terjadi pada komponen mobil beserta solusinya yang berbentuk rujukan langkah troubelshooting terhadap masalah kerusakan komponen, sebagai sistem pakar yang dapat mendeteksi kerusakan komponen dan masalah yang dianalisis yaitu tentang berbagai macam kerusakan yang terjadi pada komponen mobil beserta gejala, penyebab dan penyelesaian masalahnya dengan disajikan dalam bentuk aplikasi sistem pakar berbasis web. Dalam sistem diagnosa, sebuah kasus mencoba untuk mengambil kasus masa lalu yang memiliki daftar gejala yang mirip dengan gejala yang ada pada kasus baru dan menyarankan diagnosa berdasarkan kasus terbaik dengan menghitung nilai kemiripan (similarity) antar kasus. Kasus dalam sistem diagnosa harus dapat menggambarkan satu situasi diagnostik tertentu, yang memiliki gejala, kegagalan dan penyebab, fitur nilai/ bobot, perbaikan solusi dan hasil, dan yang terpenting kasus bukanlah sebuah aturan (teori). Adapun penjelasan dari proses-proses sistem diagnosa kerusakan sepeda motor adalah sebagai berikut: 1) Kasus baru merupakan masalah yang harus diselesaikan di dalam sistem, kasus baru yang muncul ini disebut dengan kasus target. Kasus target dalam

3 50 suatu situasi diagnostik memiliki: kategori kerusakan dan gejala-gejala yang akan di cari solusinya untuk di sarankan pada kasus target. 2) Sistem mencari kasus-kasus lama yang berada didalam basis pengetahuan / basis kasus, kemudian menghitung nilai kemiripan (similarity) dari setiap kasus. Jika kemiripan kasus memiliki nilai tinggi maka kasus tersebut akan dibandingkan dengan kasus target. 3) Ketika kasus lama memiliki nilai kemiripan yang tinggi maka solusi dari kasus lama tersebut akan diusulkan sebagai solusi pada kasus target. 4) Setelah kasus target mendapatkan solusinya, kemudian penanganan pun dilakukan terhadap mobil, setelah penaganan kerusakan berhasil dilakukan, maka teknisi diharuskan melakukan proses revisi dan perbaikan pada solusi yang sudah disarankan. Proses ini dilakukan di luar sistem diagnosa, dimana untuk merevisi kasusnya harus berdasarkan pada keberhasilan penanganan masalah yang pernah ditangani. Adapun kriteria dari proses revisi yaitu kebenaran solusi, kualitas solusi dan lain-lain (misal: preferensi pengguna). 5) Proses terakhir adalah ketika kasus sudah direvisi dan menghasilkan solusi yang berkualitas maka kasus target yang sudah direvisi tersebut akan disimpan kedalam basis kasus untuk dijadikan sebagai kasus baru di dalam basis pengetahuan. Proses perancangan aplikasi Sistem Pakar Penentuan Solusi Perbaikan Kerusakan Mobil Toyota Altis meliputi perancangan knowledge base, database, UML (Unified Modeling Language), dan user-interface. a. Perancangan knowledge base dan database

4 51 Knowledge-base (Basis Pengetahuan) yang digunakan dalam aplikasi sistem pakar ini berdasarkan CD buku manual service resmi Toyota Corolla Altis yang diproduksi oleh PT.Toyota Astra Motor (2008). Menjelaskan service atau diagnosis kerusakan semua komponen mobil toyota corolla altis. Secara umum isi dalam CD manual tersebut lebih difokuskan untuk diagnosis mobil produk toyota yaitu corolla altis. Karena pertimbangan keterbatasan waktu, penulis menggunakan 10 jenis kategori kerusakan komponen mobil, tetapi dikemudian hari knowledge-base masih dapat dikembangkan dengan mudah karena struktur knowledge-base terpisah dari source code. 10 jenis kategori kerusakan komponen mobil tersebut adalah : 1) Mesin 2) Transmisi 3) Drive Line 4) Suspensi & Axle 5) Rem 6) Steering 7) Sistem Heater & Air Conditioning 8) Kelistrikan Bodi 9) Bodi 10) Sistem Komunikasi Mekanisme inferensi yang digunakan Aplikasi Sistem Pakar ini untuk menyajikan knowledge-base pada pengguna adalah teknik Case- Based Reasoning (CBR). Proses inferensi dimulai dengan mengumpulkan

5 52 beberapa kasus yang pernah dialami oleh user sebagai teknisi untuk dibandingkan dengan beberapa kasus yang sedang dihadapi, kemudian dengan menampilkan beberapa pertanyaan yang disajikan dengan memilih kategori dan gejala-gejala (fakta-fakta) mulai dari kategori-kategori kerusakan yang bersifat umum kemudian gejala-gejala kerusakannya sehingga ditemukan jawaban atau solusi yang diberikan mesin. Untuk menghubungkan teknik inferensi dengan knowledge base, setiap data pada knowledge-base dikodefikasi untuk memudahkan dalam menampilkannya pada aplikasi. Data pertama pada suatu tabel diagnosis dimulai dengan kode DIG, kemudian kode pada data sesudahnya ditambah karakter angka. Selain itu juga data berupa detail dari pertanyaan atau jawaban yang berfungsi untuk memberikan penjelasan lebih lanjut tentang pertanyaan ataupun jawaban yang ditampilkan oleh aplikasi Sumber Informasi Data mengenai troubelshooting kerusakan komponen mobil, yaitu prinsip troubelshooting, gejala-gejala kerusakan komponen mobil, penyebab kerusakan serta solusi yang diusulkan didapatkan dari buku-buku mengenai solusi perbaikan dan buku panduan service dan langkah-langkah penanganannya. Selain itu, informasi mengenai diagnosis dan menyelesaikan masalah kerusakan komponen mobilnya didapat dari pakar dan manual service toyota altis itu sendiri Identifikasi Masalah Langkah pertama dalam pembangunan sistem pakar ini adalah mengidentifikasi permasalahan yang akan dikaji, dalam hal ini dengan mengidentifikasi permasalahan kerusakan komponen sparepart, adapun masalah-

6 53 masalah yang akan diambil dalam pembangunan sistem pakar penentuan solusi kerusakan mobil toyota corolla altis Konseptualisasi Identifikasi kerusakan sparepart mobil toyota altis memang sangat membutuhkan pengalaman dan pengetahuan yang cermat untuk dapat mengenal ciri-ciri kerusakan beserta gejala-gejala kerusakan dan sebabsebab utama kerusakan yang terjadi. Karena banyak sekali gejala-gejala kerusakan yang hampir sama apabila tidak memiliki kejelian dan ketelitian untuk menelusurinya. Oleh karena itu diperoleh suatu konsep untuk mengembangkan sistem pakar ini, yaitu proses identifikasi jenis kerusakan pada sparepart mobil corolla altis dan bagaimana caranya untuk menanggulangi dan menentukan solusi dari kerusakan tersebut. Dimana dapat dilakukan dengan memperhatikan bagian-bagian pada sparepart mobil atau bagian-bagian mobil yang tampak jelas yang membedakan antara ciri-ciri gejala yang timbul pada bagian kerusakan tersebut. Dalam tahapan konseptualisasi merupakan tahap dimana knowledge engineer dan pakar menentukan konsep yang akan dikembangkan menjadi sistem pakar yang dapat memberikan kemudahan untuk dipergunakan dan memiliki kemampuan diagnosis yang baik nantinya. Dari seluruh konsep yang dikaji dan dirinci unsur-unsur yang terlibat serta menentukan hubungan dan mekanisme pengendalian yang diperlukan unutk mencapai solusi.

7 Representasi Pengetahuan Sistem diagnosis yang akan dibuat adalah sistem diagnosis aturan. Pengetahuan direpresentasikan dengan menggunakan aturan bentuk IF-THEN. Sistem diagnosis bekerja untuk mendapatkan solusi berdasarkan gejala-gejala awal yang diamati. Representasi pengetahuan yang digunakan yaitu tabel gejala, tabel diagnosa, kaidah kerusakan yang dialami dan solusi yang dihasilkan Tabel Gejala Cara representasi pengetahuan yang tepat diperlukan untuk membuat suatu sistem pakar agar dapat melakukan penalaran yang baik. Perancangan basis pengetahuan (knowledge base) ini dimulai dengan membuat tabel gejala. Tabel 3.1 merupakan tabel kategori kerusakan dari sistem pakar yang akan dibangun. Tabel 3.1 Tabel Kategori Kerusakan Kode KK01 KK02 KK03 KK04 KK05 KK06 KK07 KK08 KK09 KK10 KK11 Nama Kategori Mesin Transmisi Drive Line Suspensi & Axle Rem Steering Sistem Heater & Air Conditioning Kelistrikan Bodi Bodi Sistem Komunikasi Keamanan

8 Tabel Kerusakan Kemudian cara representasi pengetahuan yang tepat diperlukan untuk membuat suatu sistem pakar agar dapat melakukan penalaran yang baik. Tabel 3.2 merupakan tabel gejala dari sistem pakar yang akan dibangun. Tabel 3.2 Tabel Gejala Kerusakan Kode A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 B1 B2 B3 B4 C1 C2 D1 D2 E1 E2 F1 Nama Gejala Mesin tidak dapat berputar (Tidak hidup) Tidak terdapat pembakaran awal (Tidak hidup) Mesin berputar normal tetapi sulit dihidupkan Terjadi pembakaran intermittent yang tidak sempurna (Tidak hidup) Putaran mesin tinggi (Idle buruk) Mesin mati saat deselerasi Mesin mati saat pengoperasian air conditioning Akselerasi tersendat-sendat/buruk (Pengendaraan buruk) Putaran mesin rendah (Idle buruk) Mesin mati setelah hidup Tidak ada up-shift (Terutama gear, dari gear ke-1 ke ke-4 Tidak dapat up-shift (dari 3st ke 4th ) Kendaraan tak mau bergerak dalam posisi maju maupun mundur Kendaraan tak mau bergerak dalam posisi R Roda depan semi Roda belakang semi Kendaraan menarik ke satu sisi selama pengendaraan Sempoyongan atau menarik Anti-Lock Brake System (Sistem Rem Anti Slip) atau EBD tidak bekerja Lampu peringatan BRAKE abnormal (Tidak hidup) Steering berat

9 56 F2 G1 G2 H1 H2 H3 I1 I2 I3 Tenaga balik lemah Seluruh fungsi sistem A/C sistem tidak bekerja Kontrol Temperatur: Tidak ada kontrol temperatur Satu sisi LO-beam headlight tidak menyala Lampu kabut belakang tidak menyala Satu sisi lampu rem tidak menyala Power window tidak bekerja dengan switch master regulator power window Fungsi AUTO UP/DOWN tidak bekerja pada sisi pengemudi AUTO beroperasi tidak sepenuhnya menutup power window pada sisi pengembangan Aturan Kaidah Produksi Kaidah produksi biasanya dituliskan dalam bentuk IF-THEN, kaidah ini dapat dikatakan sebagai hubungan implikasi dua bagian yaitu bagian premis (jika) dan bagian konklusi (maka), apabila bagian premis dipenuhi, maka bagian konklusi juga akan bernilai benar. Untuk masingmasing area gejala, terdapat juga aturan kaidah produksi gejala penyakit dalam bentuk IF-THEN rules. Sebagai contoh, dapat dilihat IF-THEN rules gejala penyakit dari area kerusakan komponen mesin : Rule 1 : IF Mesin tidak berputar (tidak hidup) AND Tidak terdapat pembakaran awal (tidak hidup) AND Mesin berputar normal tetapi sulit dihidupkan AND Terjadi pembakaran intermittent yang tidak sempurna THEN Periksa voltase baterai dan crank (putar) mesin lebih dari 10 detik

10 57 Rule 2 : IF Mesin mati saat pengoperasian air conditioning AND akselesari tersendat-sendat/buruk AND Mesin mati setelah dihidupkan THEN Lepas hubungan kabel dari terminal negatif baterai dan cek sistem bahan bakar penempatan spare part Gejala-Gejala Kerusakan Mobil Gejala kerusakan mobil adalah sinyal-sinyal kerusakan yang menandakan ada sesuatu yang tidak beres dalam mobil. Setiap kategori kerusakan memiliki satu atau banyak gejala yang merepresentasikan sesuatu yang tidak beres pada satu kategori tertentu. Penentuan bobot pada setiap gejala sangatlah penting, karena bobot yang diberikan sangat mempengaruhi ketepatan diagnosa dan solusinya. Bobot dari gejala kerusakan berkisar antara 0,1-1. Bobot tersebut bersumber dari bengkel yang didasarkan pada tingkat besar kecilnya kerusakan yang dapat diakibatkan oleh gejala tersebut, dengan asumsi semakin besar bobot yang diberikan maka tingkat kerusakannya semakin besar. Bobot yang diberikan kepada setiap gejala adalah berbeda-beda. Diagnosa kerusakan mobil adalah upaya identifikasi untuk mengetahui jenis kerusakan yang dialami oleh mobil. Gejala-gejala yang terjadi pada mobil hanya akan ditangani jika mengarah pada satu kasus sehingga akan menghasilkan satu diagnosa dan satu solusi untuk kerusakan komponen mobil.

11 58 1) Contoh Kasus Penerapan Metode Case Based Reasoning Langkah 1 : Input kategori kerusakan dan gejala kerusakan merupakan tahap awal yang harus dilakukan oleh teknisi, seperti contoh kasus target di bawah ini : Tabel 3.3. Contoh Input Kasus Target Kategori kerusakan Mesin Mesin Mesin Transmisi Transmisi Gejala Kerusakan A1 A5 A7 B3 B4 Langkah 2 : Cari kasus pada database, hasil pencarian kasus lama pada basis kasus adalah sebagai berikut : Kode Kasus Tabel 3.4. Contoh Hasil Pencarian Kasus Lama di Basis Kasus Kasus Solusi Diagnosa Solusi Gejala KS0001 A1, Tidak ada bensin KS0002 KS0003 KS0004 A1, A10, A2, A3, B1, Tidak ada pengapian/ pengapian tidak normal A1, A6, E2, Kompresi bocor A1, A2, A4, D2, T1, T2, Busi kotor/ aus/rusak Periksa tangki bensin, isi bensin jika kosong. Cek arus listrik yang ke coil, jika rusak, ganti spark plug dan coil. Dan lakukan pengecekan accu. Gunakan alat ukur compression tester, tancapkan pada ulir lubang busi, kemudian mesin diengkol untuk mengetahui besarnya tekanan psi standar pada masing-masing tipe motor. Bersihkan busi dengan ampelas atau ganti busi jika hasil pengapian kurang sempurna atau mati. KS0013 A5, CDI rusak Ganti CDI KS0016 A7, Seal valve aus Ganti SEAL VALVE. KS0017 A7, D2, Kopling otomatis Ganti CLUTCH.

12 59 KS0019 A1, A9, Langkah 3 : aus Rumah kopling baru, plat kopling bekas/ baru tetapi tidak di setel Lakukan penyetelan pada kopling, ganti CLUTCH HOUSING COMP. kasus. Gunakan pembobotan untuk menentukan prioritas masing-masing atribut Langkah 4 : Tabel 3.5. Contoh Pembobotan Kasus Target Kateori kerusakan Bobot Gejala Kerusakan Bobot Mesin 4 A1 9 Mesin 4 A5 7 Mesin 4 A7 4 Transmisi 2 B1 10 Transmisi 2 B sebagai berikut : Memasuki proses similarity kasus dengan menggunakan rumus Sim (S,T) =... (1) Kode Kasus Tabel 3.6. Tabel Perhitungan Similarity A1 A5 A7 B1 B4 Similarity KS KS KS KS KS KS KS KS

13 60 Langkah 5 : Hasil dari perhitungan nilai similarity yang memiliki nilai tertinggi adalah KS0002, maka diagnosa dan solusi yang digunakan untuk kasus target adalah diagnosa dan solusi dari KS0002. Tabel 3.7. Tabel Hasil / Solusi Kode Kasus Diagnosa Solusi KS0002 Tidak ada pengapian/ pengapian tidak normal Cek arus listrik yang ke coil, jika rusak, ganti spark plug dan coil. Dan lakukan pengecekan accu. Langkah 6 : Untuk mengetahui kriteria kemiripan diagnosa dan solusi yang dimiliki oleh kasus target, yaitu dengan menggunakan rumus dari perhitungan fungsi keanggotaan logika fuzzy. Nilai hasil perhitungan similariy (Sim) = 0,86 Tabel 3.8. Tabel Hasil Akhir Perhitungan Rendah Sedang Tinggi 0 x 0,5 0,45 x 0,75 0,7-1 adalah : Sim masuk kedalam kriteria tinggi, sehingga rumus yang digunakan µ(tinggi) = x - 0,7 0,15

14 61 0,86-0,7 = = 1 0,15 Dari perhitungan di atas dapat disimpulkan bahwa tingkat kemiripan kasus lama dengan nilai similarity 0,86 memiliki kriteria kemiripan tinggi dengan kasus target Identifikasi Input Pada proses identifikasi input, yang diperlukan adalah melakukan pengumpulan data atau informasi yang mendukung dalam pembangunan aplikasi sistem pakar untuk mendeteksi dan memecahkan masalah komponen mobil. Sistem akan mengajukan beberapa pertanyaan kepada pengguna, dimana pertanyaan ini adalah salah satu cara sistem dalam mengumpulkan informasi tentang suatu masalah yang hendak dipecahkan. Untuk menjawab pertanyaan yang ditampilkan pada layar monitor, pengguna cukup memilih jawaban ya atau tidak Identifikasi Output Setelah sistem pakar menerima masukan dari pengguna melalui berbagai pertanyaan yang diajukan oleh sistem, maka sistem akan memberikan kesimpulan dari jawaban pertanyaan tersebut dan sistem akan mengakumulasi berbagai jawaban dari pengguna, dimana masing-masing jawaban itu akan sangat mempengaruhi kesimpulan yang didapat. Dimana sistem akan memberikan informasi tentang letak kerusakan yang terjadi beserta penjelasan solusi penanganan kerusakannya.

15 Analisis Kebutuhan Non Fungsional Kebutuhan non fungsional adalah usulan yang direkomendasikan kepada pengguna agar komponen yang akan dibangun adalah komponen yang mudah dan cepat untuk diatasi, dan perangkat kerasnya dapat mendukung secara maksimal terhadap kinerja komponen mobilnya. a) Analisis User Analisis user dimaksudkan untuk mengetahui siapa saja user yang terlibat beserta karakteristiknya sehingga dapat diketahui tingkat penglaman dan pemahaman user terhadap komponen mobil. Adapun user yang dapat menggunakan sistem adalah sebagai berikut : 1) Masyarakat umum yang ingin mengetahui letak permasalahan dan memecahkan permasalahan yang terjadi pada komponen mobilnya. 2) Teknisi komponen mobil yang menjadi Pakar. 3) Mahasiswa teknik komputer atau informatika yang dapat menjadikan aplikasi sistem pakar ini sebagai media pembelajaran terhadap suatu kerusakan komponen mobilnya. 4) Suatu instansi dalam membantu penanganan kerusakan komponen mobil, menekan biaya service oleh tenaga ahli. User yang dapat menggunakan sistem umumnya sudah bisa mengoperasikan komputer dan mengakses internet, dari data keseluruhan dapat disimpulkan bahwa setiap user minimal dapat mengetahui sedikitnya tentang nama-nama komponen mobil beserta bentuk fisiknya.

16 63 Terdapat pokok-pokok yang menjadi evaluasi dari analisis terhadap user, diantaranya adalah dalam menentukan target pengguna dari sistem yang akan dibangun. b) Analisis Perangkat Keras Perangkat keras (hardware) minimum yang direkomendasikan untuk menjalankan aplikasi sistem pakar ini adalah sebagai berikut : 1) Processor Intel Pentium III 2) Memory (RAM) minimal 512 Mb 3) VGA Card minimal 512 Mb 4) Monitor, mouse dan keyboard c) Analisis Perangkat Lunak Pemodelan analisis perangkat lunak yang digunakan adalah sistem operasi Microsoft Windows 7 Profesional, bahasa pemrogramannya menggunakan PHP dengan toolnya Notepad++, menggunakan databasenya yaitu MySQL serta software compilernya yaitu XAMPP Requirement Model Model representasi aliran proses yang akan dirancang dan disajikan yaitu dalam bentuk UML (Unified Model Language). UML digunakan untuk menggambarkan aliran inforasi dan proses data yang bergerak dari input data hingga output. UML memudahkan user yang kurang menguasai bidang komputer untuk mengerti sistem yang akan dikerjakan atau dikembangkan.

17 Identifikasi Aktor Pada aplikasi sistem pakar ini didentifikasikan beberapa aktor yaitu user/ teknisi dan admin. Tabel 3.9 Identifikasi Aktor No Nama Aktor Deskripsi 1 User Aktor yang berinteraksi langsung dengan sistem, aktor user merupakan orang yang berhubungan langsung dengan mobilnya seperti orang teknisi dan pengguna mobilnya. 2 Admin Aktor yang memegang semua akses dalam pengaturan aplikasi Use Case Diagram Sistem Pakar Penentuan Solusi Perbaikan Kerusakan Mobil Toyota Corolla Altis Use Case Diagram berfungsi untuk melihat proses apa saja yang dilakukan aktor terhadap sistem dalam bentuk use case adapun use case diagram dari sistem pakar ini terlihat dalam gambar berikut ini : Gambar 3.1. Use Case Diagram Admin Sistem Pakar

18 65 Berikut ini adalah gambar use case diagram admin pada halaman kategori kerusakan komponen kendaraannya, setelah membuat use case gambar diatas secara umum. Maka gambar berikut ini akan dibahas gambar use case secara khusus. Gambar 3.2. Use Case Diagram Admin halaman Kategori Kerusakan Berikut ini adalah gambar use case diagram admin pada halaman gejala kerusakan komponen kendaraannya, setelah membuat use case gambar secara umum. Maka gambar berikut ini akan dibahas gambar use case secara khusus.

19 66 Gambar 3.3. Use Case Diagram Admin halaman Gejala Kerusakan Berikut ini adalah gambar use case diagram admin pada halaman basis kasus komponen kendaraannya, setelah membuat use case gambar secara umum. Maka gambar berikut ini akan dibahas gambar use case secara khusus. Gambar 3.4. Use Case Diagram Admin halaman Basis Kasus

20 67 Gambar 3.5. Use Case Diagram User Sistem Pakar Dari gambaran use case pada gambar diatas dapat didefinisikan terdapat dua aktor yang terkait dengan sistem pakar ini yaitu Admin dan User. Berikut merupakan penjelasan use case diagram diatas : Tabel Penjelasan Use Case Diagram Aktor Input Nama Use Case Deskripsi Use Case Admin User name, Password Kategori Kerusakan Gejala Kerusakan Fungsi dari use case ini adalah untuk mengelola data kategori kerusakan, mulai dari tambah,edit dan hapus. Fungsi dari use case ini adalah untuk mengelola data gejala kerusakan komponen mobil.

21 68 Basis Kasus Manage User Fungsi dari use case ini adalah untuk mengelola data beberapa kasus yang dialami dengan kerusakan komponen mobil. Fungsi dari use case ini adalah untuk mengelola data user sebagai pengguna sistem pakar ini User User name, Password Kategori Kerusakan Fungsi dari use case ini adalah melihat dan memilih kategori kerusakan komponen Gejala Kerusakan Diagnosa Kerusakan Hasil Perhitungan Similarity mobil Fungsi dari use case ini adalah melihat dan memilih gejala kerusakan komponen mobil setelah memilih kategori kerusakannya Fungsi dari use case ini adalah melihat hasil diagnosa yang dilakukan oleh sistem Fungsi dari use case ini adalah melihat hasil perhitungan atau persentase kedekatan kasus dan hasil diagnosanya

22 69 Product Contact Admin Fungsi dari use case ini adalah melihat product terbaru dari toyota Fungsi dari use case ini adalah melihat contact admin dan peta lokasinya Class Diagram untuk Sistem Pakar Penentuan Solusi Perbaikan Kerusakan Mobil Toyota Altis Berikut ini adalah gambar untuk class diagram pembuatan sistem pakar yang akan dibuat, class diagram ini merupakan penterjemahan dari basis data yang telah dibuat sebelumnya. kategori +kodekategori +namakategori +bobotkategori gejala +kodegejala +namagejala +bobotgejala history +kodehistori +tanggaldiagnosa +kodeuser +kodediagnosa +kodegejala basiskasus +kodekasus +kodekategori +kodegejala +kodediagnosa +status diagnosa +kodediagnosa +namadiagnosa +solusi user +kodeuser +namateknisi +namauser +kodeakses gambar +kodegambar +alamatgambar +kodediagnosa Gambar 3.6. Class Diagram Sistem Pakar

23 70 Penjelasan class diagram dari gambar 3.7: a) Class kategori untuk menampilkan data kategori kerusakan yang dialami oleh mobil sebelum ke menu gejala. b) Class gejala untuk menampilkan data gejala kerusakan yang dialami oleh mobil setelah memilih beberapa kategori kerusakan, maka akan tampil halaman gejala yang sesuai dengan kategori yang dipilih. c) Class diagnosa dan class basis kasus, yaitu untuk menampilkan diagnosa penyelesaian masalah kerusakan sesuai dengan basis kasus yang terdapat didalam database. d) Class user untuk menampilkan pengguna sistem pakar ini, yang kebetulan disini terdapat dua pengguna yaitu admin dan user. e) Class history untuk menyimpan data-data riwayat pengguna sistem baik itu sebagai admin maupun user, semuanya akan tersimpan di class tersebut f) Class gambar yaitu untuk menampilkan gambar-gambar yang tersedia didalam sistem sebagai penunjang penggunaan sistemnya Activity Diagram untuk Sistem Pakar Penentuan Solusi Perbaikan Kerusakan Mobil Toyota Altis Diagram aktivitas (Activity Diagram) digunakan untuk menggambarkan urutan aktivitas yang dilakukan dalam sistem, mulai dari awal terjadinya aliran aktivitas, percabangan akibat pengambilan keputusan, pengulangan, serta keberadaan aksi paralel. Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga

24 71 digunakan untuk aktifitas lainnya seperti use case atau interaksi. Berikut ini activity diagram Sistem Pakar Penentuan Solusi Perbaikan Kerusakan Mobil Toyota Altis : a Activity Diagram untuk user sistem pakar 1) User memasuki halaman utama sistem pakar 2) User memilih form login untuk masuk kedalam sistem 3) Setelah user login, maka akan masuk ke halaman pertama sistem yaitu halaman kategori kerusakan. User memilih kategori kerusakannya kemudian pilih tombol submit untuk ke halaman berikutnya 4) Pada halaman selanjutnya yaitu halaman gejala kerusakan, user memilih gejala kerusakan yang dialami setelah memilih kategori kerusakannya 5) Setelah memilih gejalanya user kemudian akan melihat hasil diagnosa yang dilakukan sistem dan perhitungan similarity kerusakan yang dialami user. Gambar 3.7. Activity Diagram Halaman User (teknisi) Sistem Pakar

25 b Activity Diagram untuk admin sistem pakar 1) Admin memasuki halaman utama admin sistem pakar 2) Admin memilih form login untuk masuk kedalam sistem 3) Setelah admin login, maka akan masuk ke halaman pertama sistem yaitu halaman beranda sistem pakar halaman admin. Admin dapat memilih beberapa menu untuk dikelola datanya yaitu menu kategori, menu gejala, menu kasus, menu user. 4) Pada halaman selanjutnya yaitu halaman pengolahan data. Dibagian ini admin dapat mengelola semua data dimulai dari tambah, edit dan hapus serta menentukan bobot nilai untuk setiap gejala kerusakannya. Gambar 3.8. Activity Diagram Halaman Admin Sistem Pakar menu Kategori kerusakan

26 73 Pada gambar berikut ini merupakan activity diagram untuk halaman admin sistem untuk menu gejala kerusakan. Gambar 3.9 merupakan pembuatan alur diagram aktivitasnya. Gambar 3.9. Activity Diagram Halaman User Sistem Pakar menu Gejala Pada gambar berikut ini merupakan activity diagram untuk halaman admin sistem untuk menu basis kasus. Gambar 3.10 merupakan pembuatan alur diagram aktivitasnya.

27 74 Gambar Activity Diagram Halaman User Sistem Pakar menu Basis Kasus dan Manage User Sequence diagram Sequence diagram dipergunakan dalam menggambarkan interaksi antar objek pada sistem berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). 1. Admin atau pakar melakukan proses login sebelum masuk ke menu utama pakar/ administrator yang berfungsi sebagai pakar dari aplikasi ini. Langkah awal admin menginputkan username dan password, kemudian system akan melakukan validasi apakah username dan password terdaftar sebagai pakar/admin di sistem ini, apabila benar maka akan tampil menu utama pakar kalau tidak maka akan kembali ke menu login di awal. Dapat dilihat pada gambar 3.11:

28 75 Admin System Database Tampil Halaman Login Masukan Username & Password Cek Username & Password Valid Tampil Menu Sistem Pakar Masukan Username & Password Invalid Gambar Sequence Diagram Admin proses Login 2. Pengguna atau user ingin melakukan proses konsultasi untuk mengetahui kerusakan maka tahap awal yang akan dikerjakan ialah masuk ke dalam menu utama, kemudian memilih menu konsultasi pada menu tersebut, setelah itu akan muncul data kerusakan dan kemudian user/pengguna memilih kerusakan. Lalu sistem akan mengolah dan menampilkan kategori kerusakan yang akan dipilih oleh user/pengguna dan user harus memilih untuk mengatahui bagian kerusakan. Dapat dilihat pada gambar 3.12:

29 76 User Sistem Database Tampil Menu Utama Pilih Kategori Kerusakan Tampil Kategori Kerusakan Pilih Gejala Kerusakan Cek Gejala dan Kasus Tampil Gejala Kerusakan Pertanyaan Jawab Pertanyaan Diagnosa Kerusakan Solusi Ditampilkan Tampil Hasil Diagnosis Gambar 3.12 Sequence diagram proses diagnosis 3.3 Perancangan Basis data Basis data digunakan untuk menyimpan data-data penunjang kedalam sistem, basis data yang dibangun yaitu menggunakan MySQL.Dalam aplikasi sistem pakar ini, terdapat lebih dari satu macam jenis diagnosis. Tiap diagnosis dan data-datanya akan disimpan dalam tabel. Untuk itu dalam desain database yang akan digunakan terdapat dalam tabel berikut ini : 1). Tabel Diagnosa Dalam tabel ini disimpan data tentang jenis diagnosis yang terdapat pada sistem pakar termasuk pertanyaan dan solusi atau jawaban. Field kodediagnosa

30 77 menunjukan nama tabel dari suatu diagnosa. Sedangkan namadiagnosa dan solusi menunjukan nama diagnosa beserta solusi yang dihasilkannya. Satu diagnosa menggunakan satu buah tabel, jadi jumlah tabel jenis ini adalah sama dengan jumlah diagnosa yang tersedia dalam sistem. Nama Tabel : Tabel Diagnosa Kunci Utama : Kodediagnosa Jenis Fungsi : Master : Tabel diagnosa digunakan digunakan untuk menyimpan daftar diagnosa kerusakan yang pernah dialami Tabel Struktur Tabel Diagnosa No Nama Field Tipe Panjang Keterangan 1 Kodediagnosa Char No Unique 2 Namadiagnosa Varchar No - 3 Solusi Varchar No - 2). Tabel Basis Kasus Dalam tabel ini disimpan tentang beberapa kasus yang terjadi sebelumnya sebagai bahan referensi kasus yang akan terjadi pada waktu yang akan datang. Didalamnya terdapat 5 field, yaitu kodekasus, kodekategori, kodegejala, kodediagnosa dan status. Seperti pada tabel berikut ini : Nama Tabel : Tabel basis kasus Kunci Utama : Kodekasus Jenis Fungsi : Master : Tabel basis kasus digunakan digunakan untuk menyimpan daftar beberapa kasus kerusakan yang pernah dialami.

31 78 Tabel Struktur Tabel Basis Kasus No Nama Field Tipe Panjang Keterangan 1 Kodekasus Char No Unique 2 Kodekategori Varchar No Unique 3 Kodegejala Varchar No Unique 4 kodediagnosa Varchar No 5 status Int No 3). Tabel Gejala Tabel ini disimpan beberapa jenis gejala yang dialami atau jenis gejala kerusakan komponen mobil yang disertai dengan bobot penilaian setiap gejala untuk mencari solusi yang diinginkan berdasarkan kasus-kasus yang ada. Adapun perancangan tabel databasenya adalah sebagai berikut : Nama Tabel : Tabel Gejala Kunci Utama : Kodegejala Jenis Fungsi : Master : Tabel gejala digunakan digunakan untuk menyimpan daftar gejala kerusakan Tabel Struktur Tabel Gejala No Nama Field Tipe Ukuran Keterangan 1 Kodegejala varchar 3 2 Namagejala Varchar 70 3 Bobotgejala Int 2 4). Tabel Kategori Tabel kategori ini menyimpan data kategori kerusakan secara umum sebelum masuk kepada gejala yang dialami atau secara khusus. Ketika kategori

32 79 kerusakan dipilih maka yang akan keluar yaitu kategori kerusakan komponen secara umum yang akan memberikan pilihan untuk ke tahap berikutnya. Adapun perancangan tabel databasenya adalah sebagai berikut : Nama Tabel : Tabel kategori Kunci Utama : Kodekategori Jenis Fungsi : Master : Tabel kategori digunakan digunakan untuk menyimpan daftar kategori kerusakan yang ada di sistem Tabel Tabel Kategori No Nama Field Tipe Panjang 1 Kodekategori varchar 4 2 Namakategori Varchar 15 3 Bobotkategori Int 2 5). Tabel User Pada tabel ini disimpan data user aplikasi, siapa saja yang menggunakan sistem pakar ini. Yang didalamnya terdapat 5 field, yaitu kodeuser, namateknisi, namauser, kodeakses dan level. Berikut ini perancangan databasenya : Nama Tabel : Tabel user Kunci Utama : Kodeuser Jenis Fungsi : Master : Tabel user digunakan digunakan untuk menyimpan daftar user Pengguna sistem pakar

33 80 Tabel Tabel User No Nama Field Tipe Ukuran 1 Kodeuser Int 2 2 Namateknisi Text - 3 Namauser Text - 4 Kodeakses Varchar 50 5 Level Varchar 1 6). Tabel History Pada tabel ini disimpan data-data semua aktivitas yang dilakukan user terhadap sistem, maka akan direkam disini. Dimulai dari kapan melakukan diagnosa kerusakan hingga sampai terakhir mengunakan sistem. Adapun perancangan databasenya adalah sebagai berikut : Nama Tabel : Tabel History Kunci Utama : Kodehistory Jenis Fungsi : Master : Tabel diagnosa digunakan digunakan untuk menyimpan daftar history Penggunaan sistem pakar Tabel Tabel History No Nama Field Tipe Ukuran 1 Kodehistory Int 7 2 tanggaldiagnosa datetime - 3 kodeuser Text - 4 Kodediagnosa Varchar 7 5 kodegejala Varchar 10

34 81 7). Tabel Gambar Tabel ini berisi beberapa gambar pendukung sistem, baik itu gambar product maupun tata cara penyelesaian kerusakan komponen. Dengan adanya fasilitas ini diharapkan user lebih mudah menggunakan sistem dan memahami gejala yang dialami atau kasus yang ada sebagai diagnosa dan memunculkan solusi yang dihasilkan sistem yang tentunya sesuai dengan yang diharapkan. Adapun perancangan tabelnya adalah sebagai berikut : Nama Tabel : Tabel gambar Kunci Utama : Kodegambar Jenis Fungsi : Master : Tabel gambar digunakan digunakan untuk menyimpan daftar gambar Solusi penyelesaian kerusakan Tabel Tabel Gambar No Nama Field Tipe Ukuran 1 Kodegambar Int 2 2 Alamatgambar Text - 3 Kodediagnosa Text Perancangan Antarmuka (Interface ) Menu Untuk User Menu user adalah menu yang dapat dipilih oleh user. Menu user dalam program sistem pakar ini terdiri dari Home, Login, about, Product, Contact, Diagnosa, Revisi dan Logout. a) Home Halaman ini merupakan halaman utama aplikasi ketika user membuka aplikasi pertama kali. Dihalaman ini juga terdapat tiga menu utama yaitu

35 82 About, Contact dan Product. dihalaman ini juga terdapat form Login untuk user atau teknisi. User harus Login terlebih dahulu sebelum masuk kedalam menu-menu selanjutnya. User cukup memasukan username dan password yang telah tersimpan di dalam database. Setelah login akan muncul halaman utama aplikasi. Gambar dibawah ini merupakan rancangan untuk menu user, halaman home beserta form loginnya. Gambar 3.13 Rancangan Halaman Login User b) About Pada menu ini menampilkan keterangan tentang Case-Based Reasoning (CBR) secara umum. Serta pembahasan aplikasi sebagai bagian dari implementasi metode yang digunakan. Gambar dibawah ini merupakan rancangan untuk menu About :

36 83 Gambar 3.14 Rancangan Halaman Home User c) Product Pada halaman ini disediakan bermacam-macam mobil corolla altis dari berbagai seri dan spesifikasi. Tujuannya adalah untuk memudahkan user melihat mobil keluaran terbaru. Gambar dibawah ini merupakan rancangan untuk menu Product : Gambar 3.15 Rancangan Halaman Home Product

37 84 d) Contact Pada halaman ini ditampilkan nomor contact beserta yang digunakan pembuat aplikasi, sebagai identitas diri dan jika user mengalami kesulitan ketika menggunakan aplikasi ini. Gambar dibawah ini merupakan rancangan untuk menu Contact : Gambar 3.16 Rancangan Halaman Home Contact e) Diagnosa Halaman ini tampil ketika user telah melakukan login terlebih dahulu kedalam sistem. Setelah user melakukan login maka tampilan pertama yang akan tampil adalah halaman diagnosa. Pada halaman ini user akan ditampilkan beberapa kategori kerusakan komponen mobil yang akan didiagnosa, user diharuskan memilih beberapa kategori kerusakan sesuai dengan kerusakan yang dialami oleh mobil client. Kemudian dilanjutkan ke halaman diagnosa berikutnya untuk memilih gejala yang dialami oleh komponen mobil tersebut, setelah melakukan pemilihan kategori kerusakan dan gejala yang dialami oleh komponen mobil maka halaman

38 85 setelah ini akan ditampilkan solusi yang dihasilkan beserta perhitungan similarity solusinya. Gambar dibawah ini merupakan rancangan untuk menu Diagnosa : Gambar 3.17 Rancangan Halaman Kategori Pada halaman berikutnya setelah memilih kategori kerusakan, teknisi atau user ditampilkan beberapa gejala kerusakan yang sesuai dengan kategori kerusakan yang dipilih. Berikut ini merupakan gambar perancangan pembuatan halaman gejala kerusakannya. Gambar 3.18 Rancangan Halaman Gejala

39 86 Pada halaman berikutnya setelah memilih gejala kerusakan, teknisi atau user ditampilkan solusi kerusakan yang sesuai dengan gejala dan kategori kerusakan yang dipilih. Berikut ini merupakan gambar perancangan pembuatan halaman solusi diagnosa kerusakannya. Gambar 3.19 Rancangan Halaman Hasil Diagnosa f) Logout Halaman ini merupakan halaman terakhir untuk setiap aplikasi. Fungsinya untuk keluar dari aplikasi sistem pakar Menu untuk Admin Menu admin akan ditampilkan ketika admin harus login terlebih dahulu kedalam sistem dengan mengisi username dan password telah telah tersimpan di dalam database. Gambar 3.20 Rancangan Halaman Form Login Admin

40 87 Pada gambar berikut ini ditampilkan gambar perancangan halaman menu kategori untuk admin memanipulasi data kategori kerusakan. Berikut ini merupakan gambar perancangannya. Gambar 3.21 Rancangan Halaman Menu Kategori Pada gambar berikut ini ditampilkan gambar perancangan halaman menu gejala kerusakan untuk admin memanipulasi data gejala kerusakan. Berikut ini merupakan gambar perancangannya. Gambar 3.22 Rancangan Halaman Menu Gejala

41 88 Pada gambar berikut ini ditampilkan gambar perancangan halaman menu untuk basis kasus kerusakan untuk admin memanipulasi data beberapa kasus yang pernah dialami. Berikut ini merupakan gambar perancangannya. Gambar 3.23 Rancangan Halaman Menu Kasus