48 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.
3.1.1 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.
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
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.
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
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. 3.1.2 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.
3.1.3 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-masalah yang akan diambil dalam pembangunan sistem pakar penentuan solusi kerusakan mobil toyota corolla altis.
3.1.3.1 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 sebab-sebab 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.
3.1.4 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.
3.1.4.1 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 Nama Kategori
KK01 KK02 KK03 KK04 KK05 KK06 KK07 KK08 KK09 KK10 KK11 Mesin Transmisi Drive Line Suspensi & Axle Rem
Steering
Sistem Heater & Air Conditioning Kelistrikan Bodi
Bodi
Sistem Komunikasi Keamanan
3.1.4.2 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 Nama Gejala
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 B1 B2 B3 B4 C1 C2 D1 D2 E1 E2 F1
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
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
3.1.4.3 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 masing-masing 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
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 3.1.5 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.
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 Gejala Kerusakan
Mesin A1 Mesin A5 Mesin A7 Transmisi B3 Transmisi B4 Langkah 2 :
Cari kasus pada database, hasil pencarian kasus lama pada basis kasus adalah sebagai berikut :
Tabel 3.4. Contoh Hasil Pencarian Kasus Lama di Basis Kasus
Kasus Solusi
Kode
Kasus Gejala
Diagnosa Solusi
KS0001 A1, Tidak ada bensin Periksa tangki bensin, isi bensin jika kosong. KS0002 A1, A10, A2, A3, B1, Tidak ada pengapian/ pengapian tidak normal
Cek arus listrik yang ke coil, jika rusak, ganti spark plug dan coil. Dan lakukan pengecekan accu.
KS0003
A1, A6,
E2, Kompresi bocor
Gunakan alat ukur compression tester, tancapkan pada ulir lubang busi, kemudian mesin diengkol untuk mengetahui besarnya tekanan psi standar pada masing-masing tipe motor. KS0004 A1, A2, A4, D2, T1, T2, Busi kotor/ aus/rusak
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.
Sim (S,T) = aus
KS0019 A1, A9,
Rumah kopling baru, plat kopling bekas/ baru tetapi tidak di setel
Lakukan penyetelan pada kopling, ganti CLUTCH HOUSING COMP.
Langkah 3 :
Gunakan pembobotan untuk menentukan prioritas masing-masing atribut kasus.
Tabel 3.5. Contoh Pembobotan Kasus Target
Langkah 4 :
Memasuki proses similarity kasus dengan menggunakan rumus sebagai berikut :
Tabel 3.6. Tabel Perhitungan Similarity Kode Kasus A1 A5 A7 B1 B4 Similarity KS0001 1 0 0 0 0 0.40 KS0002 1 0 0 1 0 0.86 KS0003 1 0 0 0 0 0.47 KS0004 1 0 0 0 0 0.46 KS0013 0 1 0 0 0 0.43 KS0016 0 0 1 0 0 0.37 KS0017 0 0 1 0 0 0.37 KS0019 1 0 0 0 0 0.40
Kateori kerusakan Bobot Gejala Kerusakan Bobot
Mesin 4 A1 9 Mesin 4 A5 7 Mesin 4 A7 4 Transmisi 2 B1 10 Transmisi 2 B4 7 22 ... (1)
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
Sim masuk kedalam kriteria tinggi, sehingga rumus yang digunakan adalah :
µ(Tinggi) =
Rendah Sedang Tinggi
0 ≤ x ≤ 0,5 0,45 ≤ x ≤ 0,75 0,7 - 1
x - 0,7 0,15
= = 1
Dari perhitungan di atas dapat disimpulkan bahwa tingkat kemiripan kasus lama dengan nilai similarity 0,86 memiliki kriteria kemiripan tinggi dengan kasus target.
3.1.6 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.
3.1.7 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.
0,86 - 0,7 0,15
3.1.8 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.
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 1.8.1.
3.2 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.
3.2.1 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
3.2.2 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 :
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.
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.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 3.10. Penjelasan Use Case Diagram
Aktor Input Nama Use
Case
Deskripsi Use Case
Admin User name, Password
Kategori Kerusakan
Fungsi dari use case ini adalah untuk mengelola data kategori kerusakan, mulai dari tambah,edit dan hapus.
Gejala Kerusakan
Fungsi dari use case ini adalah untuk mengelola data gejala kerusakan komponen mobil.
Basis Kasus Fungsi dari use case ini adalah untuk mengelola data beberapa kasus yang dialami dengan kerusakan komponen mobil.
Manage User 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
mobil Gejala
Kerusakan
Fungsi dari use case ini adalah melihat dan memilih gejala kerusakan komponen mobil setelah memilih kategori kerusakannya Diagnosa
Kerusakan
Fungsi dari use case ini adalah melihat hasil diagnosa yang dilakukan oleh sistem Hasil
Perhitungan Similarity
Fungsi dari use case ini adalah melihat hasil perhitungan atau persentase kedekatan kasus dan hasil diagnosanya
Product Fungsi dari use case ini adalah melihat product terbaru dari toyota
Contact Admin Fungsi dari use case ini adalah melihat contact admin dan peta lokasinya
3.2.3 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.
Gambar 3.6 . Class Diagram Sistem Pakar basiskasus +kodekasus +kodekategori +kodegejala +kodediagnosa +status diagnosa +kodediagnosa +namadiagnosa +solusi gambar +kodegambar +alamatgambar +kodediagnosa gejala +kodegejala +namagejala +bobotgejala history +kodehistori +tanggaldiagnosa +kodeuser +kodediagnosa +kodegejala kategori +kodekategori +namakategori +bobotkategori user +kodeuser +namateknisi +namauser +kodeakses
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. 3.2.4 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
digunakan untuk aktifitas lainnya seperti use case atau interaksi. Berikut ini activity diagram Sistem Pakar Penentuan Solusi Perbaikan Kerusakan Mobil Toyota Altis :
3.2.4.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.
3.2.4.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.
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.
Gambar 3.10 . Activity Diagram Halaman User Sistem Pakar menu Basis Kasus dan
Manage User 3.2.5 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:
Admin System Database
Tampil Halaman Login
Masukan Username & Password
Tampil Menu Sistem Pakar
Invalid Valid Cek Username &
Password
Masukan Username & Password
Gambar 3.11. 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:
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
User Sistem Database
Tampil Menu Utama
Pilih Kategori Kerusakan
Tampil Kategori Kerusakan
Cek Gejala dan Kasus
Pertanyaan
Diagnosa Kerusakan
Solusi Ditampilkan Pilih Gejala Kerusakan
Tampil Gejala Kerusakan
Jawab Pertanyaan
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 : Master
Fungsi : Tabel diagnosa digunakan digunakan untuk menyimpan daftar diagnosa kerusakan yang pernah dialami
Tabel 3.11. 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 : Master
Fungsi : Tabel basis kasus digunakan digunakan untuk menyimpan daftar beberapa kasus kerusakan yang pernah dialami.
Tabel 3.12. 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 : Master
Fungsi : Tabel gejala digunakan digunakan untuk menyimpan daftar gejala kerusakan
Tabel 3.13 . 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
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 : Master
Fungsi : Tabel kategori digunakan digunakan untuk menyimpan daftar kategori kerusakan yang ada di sistem
Tabel 3.14. 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 : Master
Fungsi : Tabel user digunakan digunakan untuk menyimpan daftar user Pengguna sistem pakar
Tabel 3.15 . 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 : Master
Fungsi : Tabel diagnosa digunakan digunakan untuk menyimpan daftar history Penggunaan sistem pakar
Tabel 3.16 . Tabel History
No Nama Field Tipe Ukuran
1 Kodehistory Int 7
2 tanggaldiagnosa datetime -
3 kodeuser Text -
4 Kodediagnosa Varchar 7
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 : Master
Fungsi : Tabel gambar digunakan digunakan untuk menyimpan daftar gambar Solusi penyelesaian kerusakan
Tabel 3.17 . Tabel Gambar
No Nama Field Tipe Ukuran
1 Kodegambar Int 2
2 Alamatgambar Text -
3 Kodediagnosa Text -
3.4 Perancangan Antarmuka (Interface ) 3.4.1 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
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 :
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 :
d) Contact
Pada halaman ini ditampilkan nomor contact beserta email 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
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.
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.
3.4.2 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.
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.
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.
