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. 48
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
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
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 CaseBased Reasoning (CBR). Proses inferensi dimulai dengan mengumpulkan
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. 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
mengidentifikasi
pertama
dalam
permasalahan
yang
pembangunan akan
dikaji,
sistem dalam
pakar
ini
adalah
hal
ini
dengan
mengidentifikasi permasalahan kerusakan komponen sparepart, adapun masalah-
53
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 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 knowledge
tahapan engineer
konseptualisasi dan
pakar
merupakan
menentukan
tahap
konsep
yang
dimana 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.
54
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
Mesin
KK02
Transmisi
KK03
Drive Line
KK04
Suspensi & Axle
KK05
Rem
KK06
Steering
KK07
Sistem Heater & Air Conditioning
KK08
Kelistrikan Bodi
KK09
Bodi
KK10
Sistem Komunikasi
KK11
Keamanan
55
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
Mesin tidak dapat berputar (Tidak hidup)
A2
Tidak terdapat pembakaran awal (Tidak hidup)
A3
Mesin berputar normal tetapi sulit dihidupkan
A4
Terjadi pembakaran intermittent yang tidak sempurna (Tidak hidup)
A5
Putaran mesin tinggi (Idle buruk)
A6
Mesin mati saat deselerasi
A7
Mesin mati saat pengoperasian air conditioning
A8
Akselerasi tersendat-sendat/Buruk (Pengendaraan buruk)
A9
Putaran mesin rendah (Idle buruk)
A10
Mesin mati setelah hidup
B1
Tidak ada up-shift (Terutama gear, dari gear ke-1 ke ke-4
B2
Tidak dapat up-shift (dari 3st ke 4th )
B3
Kendaraan tak mau bergerak dalam posisi maju maupun mundur
B4
Kendaraan tak mau bergerak dalam posisi R
C1
Roda depan semi
C2
Roda belakang semi
D1
Kendaraan menarik ke satu sisi selama pengendaraan
D2
Sempoyongan atau menarik
E1
Anti-Lock Brake System (Sistem Rem Anti Slip) atau EBD tidak bekerja
E2 F1
Lampu peringatan BRAKE abnormal (Tidak hidup) Steering berat
56
F2
Tenaga balik lemah
G1
Seluruh fungsi sistem A/C sistem tidak bekerja
G2
Kontrol Temperatur: Tidak ada kontrol temperatur
H1
Satu sisi LO-beam headlight tidak menyala
H2
Lampu kabut belakang tidak menyala
H3
Satu sisi lampu rem tidak menyala
I1
Power window tidak bekerja dengan switch master regulator power window
I2
Fungsi AUTO UP/DOWN tidak bekerja pada sisi pengemudi
I3
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 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 AND AND AND THEN
Mesin tidak berputar (tidak hidup) Tidak terdapat pembakaran awal (tidak hidup) Mesin berputar normal tetapi sulit dihidupkan Terjadi pembakaran intermittent yang tidak sempurna Periksa voltase baterai dan crank (putar) mesin lebih dari 10 detik
57
Rule 2 : IF AND AND THEN
3.1.5
Mesin mati saat pengoperasian air conditioning akselesari tersendat-sendat/buruk Mesin mati setelah dihidupkan 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.
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 : Tabel 3.4. Contoh Hasil Pencarian Kasus Lama di Basis Kasus Kasus Solusi Kode Diagnosa Solusi Gejala Kasus Periksa tangki bensin, isi bensin jika KS0001 A1, Tidak ada bensin kosong. A1, A10, Tidak ada Cek arus listrik yang ke coil, jika A2, A3, pengapian/ KS0002 rusak, ganti spark plug dan coil. Dan B1, pengapian tidak lakukan pengecekan accu. normal Gunakan alat ukur compression tester, tancapkan pada ulir lubang A1, A6, busi, kemudian mesin diengkol untuk KS0003 E2, Kompresi bocor mengetahui besarnya tekanan psi standar pada masing-masing tipe motor. A1, A2, Bersihkan busi dengan ampelas atau Busi kotor/ KS0004 A4, D2, ganti busi jika hasil pengapian kurang aus/rusak T1, T2, sempurna atau mati. KS0013 A5, CDI rusak Ganti CDI KS0016 A7, Seal valve aus Ganti SEAL VALVE. KS0017 A7, D2, Kopling otomatis Ganti CLUTCH.
59
KS0019
aus Rumah kopling baru, plat kopling bekas/ baru tetapi tidak di setel
A1, A9,
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 Kateori kerusakan Bobot Mesin 4 Mesin 4 Mesin 4 Transmisi 2 Transmisi 2 22
Gejala Kerusakan Bobot A1 9 A5 7 A7 4 B1 10 B4 7
Langkah 4 : Memasuki proses similarity kasus dengan menggunakan rumus sebagai berikut : ................ (1)
Sim (S,T) =
Tabel 3.6. Tabel Perhitungan Similarity Kode Kasus
A1
A5
A7
B1
B4
Similarity
KS0001
1
0
0
0
0
KS0002 KS0003 KS0004 KS0013 KS0016 KS0017 KS0019
1 1 1 0 0 0 1
0 0 0 1 0 0 0
0 0 0 0 1 1 0
1 0 0 0 0 0 0
0 0 0 0 0 0 0
0.40 0.86 0.47 0.46 0.43 0.37 0.37 0.40
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 Cek arus listrik yang ke coil, jika rusak, ganti spark plug dan coil. Dan lakukan pengecekan accu.
Tidak ada pengapian/ pengapian tidak normal
KS0002
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
Sim masuk kedalam kriteria tinggi, sehingga rumus yang digunakan adalah :
x - 0,7
µ(Tinggi)
= 0,15
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. 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. informasi tentang
letak
penanganan kerusakannya.
kerusakan
yang
Dimana sistem akan memberikan terjadi beserta
penjelasan solusi
62
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.
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 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.
64
3.2.1
Identifikasi Aktor Pada aplikasi sistem pakar ini didentifikasikan beberapa aktor yaitu user/
teknisi dan admin. Tabel 3.9 Identifikasi Aktor
3.2.2
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
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.
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
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 3.10. Penjelasan Use Case Diagram Aktor Admin
Input
Nama Use Case
Deskripsi Use Case
User name, Kategori Password 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.
68
User
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 name, Kategori Password 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
69
3.2.3
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
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
gejala
+kodekategori +namakategori +bobotkategori
+kodegejala +namagejala +bobotgejala
history +kodehistori +tanggaldiagnosa +kodeuser +kodediagnosa +kodegejala
user
diagnosa basiskasus +kodekasus +kodekategori +kodegejala +kodediagnosa +status
+kodediagnosa +namadiagnosa +solusi
+kodeuser +namateknisi +namauser +kodeakses
gambar +kodegambar +alamatgambar +kodediagnosa
Gambar 3.6 . Class Diagram Sistem Pakar
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. 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
digunakan
untuk
keberadaan aksi paralel. Menggambarkan
rangkaian
aliran
dari
aktivitas,
mendeskripsikan aktifitas yang dibentuk dalam suatu operasi sehingga dapat juga
71
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.
Gambar 3.7 . Activity Diagram Halaman User (teknisi) Sistem Pakar
72
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.
Gambar 3.8 . Activity Diagram Halaman Admin Sistem Pakar menu Kategori kerusakan
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.
74
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:
75
Admin
System
Database
Tampil Halaman Login
Masukan Username & Password Cek Username & Password
Valid
Tampil Menu Sistem Pakar
Invalid
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:
76
Sistem
User
Database
Tampil Menu Utama
Pilih Kategori Kerusakan
Tampil Kategori Kerusakan
Pilih Gejala Kerusakan
Cek Gejala dan Kasus
Pertanyaan Tampil Gejala Kerusakan
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
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
: 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.
78
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
1
Kodegejala
varchar
3
2
Namagejala
Varchar
70
3
Bobotgejala
Int
2
Keterangan
4). Tabel Kategori Tabel kategori ini menyimpan data kategori kerusakan secara umum sebelum masuk kepada gejala yang dialami atau secara khusus. Ketika kategori
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
: 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
80
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
5
kodegejala
Varchar
10
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
: 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
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.
merupakan rancangan untuk menu About :
Gambar
dibawah
ini
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
rancangan untuk menu Product :
Gambar 3.15 Rancangan Halaman Home Product
ini
merupakan
84
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
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
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. 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.
Gambar 3.20 Rancangan Halaman Form Login Admin
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
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
