bab 1,2,3
TRANSCRIPT
i
Daftar Isi
BAB 1 PENDAHULUAN.................................................................................................... 1
1. 1 Latar Belakang ........................................................................................................... 1
1. 2 Perumusan Masalah .................................................................................................... 2
1. 3 Maksud dan Tujuan .................................................................................................... 2
1. 3. 1 Maksud ................................................................................................................. 2
1. 3. 2 Tujuan................................................................................................................... 2
1. 4 Batasan Masalah......................................................................................................... 2
1. 5 Metodologi Penelitian................................................................................................. 2
1. 5. 1 Metode Pengumpulan Data ................................................................................... 2
1. 5. 2 Membangunan Perangkat lunak ............................................................................ 2
1. 6 Sistematika Penulisan ................................................................................................. 4
BAB 2 LANDASAN TEORI ............................................................................................... 5
2. 1 Sistem Pakar............................................................................................................... 5
2. 1. 1 Manfaat sistem pakar. ........................................................................................... 5
2. 1. 2 Keterbatasan sistem pakar ..................................................................................... 6
2. 1. 3 Komponen sistem pakar ........................................................................................ 7
2. 2 UML (Unified Modeling language) ............................................................................ 8
2. 2. 1 Sejarah Singkat UML............................................................................................ 8
2. 2. 2 Pengenalan UML .................................................................................................. 9
2. 2. 3 Diagram UML .................................................................................................... 13
2. 2. 3. 1 Use Case ........................................................................................................................ 13
2. 2. 3. 2 Activity Diagram ........................................................................................................... 14
2. 2. 3. 3 Sequence Diagram ......................................................................................................... 15
2. 2. 3. 4 Class Diagram................................................................................................................ 15
2. 2. 3. 5 Statechart Diagram ........................................................................................................ 16
2. 2. 3. 6 Collaboration Diagram ..................................................................................................16
2. 2. 3. 7 Component Diagram...................................................................................................... 16
2. 2. 3. 8 Deployment Diagram..................................................................................................... 16
2. 2. 3. 9 Object Diagram.............................................................................................................. 17
2. 3 JAVA ....................................................................................................................... 17
2. 3. 1 Seajarah Singkat JAVA....................................................................................... 17
2. 3. 2 Pengenalan JAVA............................................................................................... 18
2. 3. 3 Beberapa Fitur-fitur Penting Dalam Bahasa Java................................................. 19
ii
2. 3. 4 Token.................................................................................................................. 21
2. 3. 5 Struktur Program JAVA...................................................................................... 22
2. 4 MySQL .................................................................................................................... 23
2. 4. 1 Sistem Manajemen Basis Data Relasional ........................................................... 23
2. 4. 2 Keistimewaan MySQL........................................................................................ 24
2. 4. 3 Bahasa Pemrograman.......................................................................................... 25
BAB 3 ANALISIS DAN PERANCANGAN SISTEM...................................................... 26
3. 1 Analisis Sistem yang Sedang Berjalan ...................................................................... 26
3. 2 Analisis Kebutuhan Non Fungsional ......................................................................... 26
3. 2. 1 Analisis Kebutuhan Perangkat Keras................................................................... 26
3. 2. 2 Analisis Kebutuhan Perangkat Lunak.................................................................. 27
3. 2. 3 Analisis Pengguna (user)..................................................................................... 27
3. 2. 4 Analisis Kebutuhan Perangkat Pikir .................................................................... 27
3. 2. 4. 1 Analisis Sistem Pakar .................................................................................................... 28
3. 2. 4. 2 Analisis Masalah............................................................................................................ 28
3. 2. 4. 3 Analisis Kebutuhan Data ............................................................................................... 28
3. 2. 4. 4 Konseptualisasi .............................................................................................................. 29
3. 3 Analisis Kebutuhan Fungsional................................................................................. 31
3. 3. 1 Identifikasi Aktor ................................................................................................ 31
3. 3. 2 Use Case Diagram............................................................................................... 32
3. 3. 2. 1 Use Case Diagram dengan Aktor Pakar (Administrator) .............................................. 34
3. 3. 2. 2 Use Case Diagram dengan Aktor Pasien ....................................................................... 35
3. 3. 3 Use Case Skenario .............................................................................................. 35
3. 3. 4 Activity Diagram ................................................................................................ 56
3. 3. 4. 1 Activity Diagram untuk Proses Login ........................................................................... 56
3. 3. 4. 2 Activity Diagram untuk Proses Manajemen Administrator........................................... 57
3. 3. 4. 3 Activity Diagram untuk Proses Manajemen Data Penyakit .......................................... 58
3. 3. 4. 4 Activity Diagram untuk Proses Manajemen Data Gejala .............................................. 59
3. 3. 4. 5 Activity Diagram untuk Proses Manajemen Data Pertanyaan....................................... 60
3. 3. 4. 6 Activity Diagram untuk Proses Manajemen Data Penanganan ..................................... 61
3. 3. 4. 7 Activity Diagram untuk Proses Manajemen Diagnosis ................................................. 62
3. 3. 5 Sequence Diagram .............................................................................................. 62
3. 3. 5. 1 Sequence Diagram untuk use case Login ...................................................................... 62
3. 3. 5. 2 Sequence Diagram untuk use case Manajemen Administrator ..................................... 63
3. 3. 5. 3 Sequence Diagram untuk use case Manajemen Data Penyakit ..................................... 64
iii
3. 3. 5. 4 Sequence Diagram untuk use case Manajemen Data Gejala......................................... 65
3. 3. 5. 5 Sequence Diagram untuk use case Manajemen Data Pertanyaan..................................66
3. 3. 5. 6 Sequence Diagram untuk use case Manajemen Data Penanganan ................................ 67
3. 3. 5. 7 Sequence Diagram untuk use case Manajemen Diagnosis ............................................ 68
3. 3. 6 Class Diagram..................................................................................................... 69
3. 3. 7 State Diagram ..................................................................................................... 71
3. 3. 7. 1 State Diagram Proses Login .......................................................................................... 71
3. 3. 7. 2 State Diagram Proses Manajemen Administrator.......................................................... 71
3. 3. 7. 3 State Diagram Proses Manajemen Data Penyakit.......................................................... 72
3. 3. 7. 4 State Diagram Proses Manajemen Data Gejala ............................................................. 73
3. 3. 7. 5 State Diagram Proses Manajemen Data Pertanyaan ...................................................... 74
3. 3. 7. 6 State Diagram Proses Manajemen Data Penanganan .................................................... 75
3. 3. 7. 7 State Diagram Proses Manajemen Diagnosis ................................................................ 76
3. 4 Perancangan Sistem.................................................................................................. 77
3. 4. 1 Perancangan Data................................................................................................ 77
3. 4. 1. 1 Skema Relasi ................................................................................................................. 77
3. 4. 1. 2 Diagram Relasi .............................................................................................................. 78
3. 4. 1. 3 Struktur File ................................................................................................................... 78
iv
Daftar Gambar
Gambar 1.1 Waterfall............................................................................................................ 3
Gambar 2.1 Struktur skematis sebuah Sistem Pakar............................................................... 7
Gambar 2.2 Sebuah Kelas dari model UML ........................................................................ 10
Gambar 2.3 Sebuah interface/antar-muka ............................................................................ 10
Gambar 2.4 Collaborations.................................................................................................. 11
Gambar 2.5 Use Case.......................................................................................................... 11
Gambar 2.6 Nodes .............................................................................................................. 11
Gambar 2.7 Dependency ..................................................................................................... 12
Gambar 2.8 Association ...................................................................................................... 12
Gambar 2.9 Generalizations ................................................................................................ 12
Gambar 2.10 Realizations ................................................................................................... 12
Gambar 3.1 Pohon Pelacakan.............................................................................................. 31
Gambar 3.2 Use Case diagram semua aktor ........................................................................ 33
Gambar 3.3 Use Case diagram dengan Aktor Pakar (Administrator) ................................... 34
Gambar 3.4 Use Case diagram dengan Aktor Pasien........................................................... 35
Gambar 3.5 Activity Diagram untuk Proses Login .............................................................. 56
Gambar 3.6 Activity Diagram untuk Proses Manajemen Administrator ............................... 57
Gambar 3.7 Activity Diagram untuk Proses Manajemen Data Penyakit............................... 58
Gambar 3.8 Activity Diagram untuk Proses Manajemen Data Gejala .................................. 59
Gambar 3.9 Activity Diagram untuk Proses Manajemen Data Pertanyaan ........................... 60
Gambar 3.10 Activity Diagram untuk Proses Manajemen Data Penanganan........................ 61
Gambar 3.11 Activity Diagram untuk Proses Manajemen Diagnosis ................................... 62
Gambar 3.12 Sequence Diagram untuk use case Login........................................................ 63
Gambar 3.13 Sequence Diagram untuk use case Manajemen Administrator ........................ 64
Gambar 3.14 Sequence Diagram untuk use case Manajemen Data Penyakit ........................ 65
Gambar 3.15 Sequence Diagram untuk use case Manajemen Data Gejala ........................... 66
Gambar 3.16 Sequence Diagram untuk use case Manajemen Data Pertanyaan .................... 67
Gambar 3.17 Sequence Diagram untuk use case Manajemen Data Penanganan................... 68
Gambar 3.18 Sequence Diagram untuk use case Manajemen Diagnosis .............................. 69
Gambar 3.19 Class Diagram................................................................................................ 70
Gambar 3.20 State Diagram Proses Login ........................................................................... 71
Gambar 3.21 State Diagram Proses Manajemen Administrator............................................ 71
v
Gambar 3.22 State Diagram Proses Manajemen Data Penyakit ........................................... 72
Gambar 3.23 State Diagram Proses Manajemen Data Gejala ............................................... 73
Gambar 3.24 State Diagram Proses Manajemen Data Pertanyaan........................................ 74
Gambar 3.25 State Diagram Proses Manajemen Data Penanganan ...................................... 75
Gambar 3.26 State Diagram Proses Manajemen Diagnosis.................................................. 76
Gambar 3.27 Diagram Relasi .............................................................................................. 78
vi
Daftar Tabel
Table 2.1 Use Case Diagram ............................................................................................... 14
Table 2.2 Activity Diagram................................................................................................. 14
Table 2.3 Sequence Diagram............................................................................................... 15
Table 2.4 Daftar Separator .................................................................................................. 22
Table 3.1 Penyakit dan gejala serta penanganannya............................................................. 29
Table 3.2 Gejala-gejala penyakit batuk................................................................................ 30
Table 3.3 Jenis penyakit batuk............................................................................................. 30
Table 3.4 Kaidah produksi .................................................................................................. 30
Table 3.5 Skenario Use Case Login..................................................................................... 35
Table 3.6 Skenario Use Case Manajemen Administrator ..................................................... 36
Table 3.7 Skenario Use Case Ubah Administrator ............................................................... 37
Table 3.8 Skenario Use case Manajemen Data Penyakit...................................................... 38
Table 3.9 Skenario Use Case Tambah Data Penyakit........................................................... 39
Table 3.10 Skenario Use Case Ubah Data Penyakit ............................................................. 40
Table 3.11 Skenario Use Case Hapus Data Penyakit............................................................ 41
Table 3.12 Skenario Use Case Lihat Data Manajemen Data Gejala ..................................... 42
Table 3.13 Skenario Use case Manajemen Diagnosis Tambah Gejala.................................. 43
Table 3.14 Skenario Use Case Ubah Gejala......................................................................... 44
Table 3.15 Skenario Use Case Hapus Gejala ....................................................................... 45
Table 3.16 Skenario Use Manajemen Data Pertanyaan ........................................................ 46
Table 3.17 Skenario Use Case Tambah Pertanyaan ............................................................. 47
Table 3.18 Skenario Use Case Ubah Pertanyaan.................................................................. 48
Table 3.19 Skenario Use Case Hapus Pertanyaan ................................................................ 49
Table 3.20 Skenario Use Case Manajemen Data Penanganan .............................................. 50
Table 3.21 Skenario Use Case Tambah Penanganan............................................................ 51
Table 3.22 Skenario Use Case Ubah Penanganan ................................................................ 52
Table 3.23 Skenario Use Case Hapus Penanganan............................................................... 53
Table 3.24 Skenario Use Case Manajemen Diagnosis ......................................................... 54
1
BAB 1
PENDAHULUAN
1. 1 Latar Belakang
Sistem pakar (expert system) adalah sistem yang berusaha mengadopsi pengetahuan manusia
ke komputer, agar komputer dapat menyelesaikan masalah seperti layaknya para pakar (expert).
Sistem pakar yang baik dirancang agar dapat menyelesaikan suatu permasalahan tertentu dengan
meniru kerja dari para pakar/ahli. Dengan pengembangan sistem pakar, diharapkan bahwa orang
awampun dapat menyelesaikan masalah yang cukup rumit yang sebenarnya hanya dapat
diselesaikan dengan bantuan para ahli. Bagi para ahli sistem pakar ini juga akan membantu
aktifitasnya sebagai asisten yang sangat berpengalaman. Pengalihan keahlian dari para ahli ke
komputer untuk kemudian dialihkan lagi ke orang lain yang bukan ahli, merupakan tujuan utama
dari sistem pakar. Proses ini membutuhkan 4 aktifitas, yaitu: tambahan pengetahuan, representasi
pengetahuan, inferensi pengetahuan dan pengalihan pengetahuan ke pengguna. Pengetahuan
yang disimpan ke komputer disebut sebagai basis pengetahuan.
Batuk merupakan mekanisme pertahanan tubuh di saluran pernapasan dan merupakan gejala
suatu penyakit atau reaksi tubuh terhadap iritasi di tenggorokan karena adanya lendir, makanan,
debu, asap, dan sebagainya. Berbahaya atau tidaknya batuk bisa diperhatikan dari perjalan batuk
serta kondisi-kondisi lain yang menyertainya. Hal ini jugalah yang menentukan apakah kita
membutuhkan penanganan serius atau cukup perawatan di rumah saja. Walaupun kadang suara
kita terdengar mengkhawatirkan tetapi umumnya batuk bukan merupakan suatu tanda yang
berbahaya. Terkadang kesibukan kita menyebabkan keterlambatan penanganan gejala batuk ini
sehingga menjadi lebih parah. Untuk itu kebutuhan informasi yang cepat dan tepat dari seorang
pakar kesehatan sangatlah dibutuhkan.
Dengan adanya kemajuan teknologi saat ini, permasalahan diatas tentunya dapat diatasi.
Teknologi mampu mengadopsi proses dan cara berpikir manusia yaitu teknologi kecerdasan
buatan. Sistem pakar adalah salah satu bagian dari kecerdasan buatan yang mengandung
pengetahuan dan pengalaman yang dimasukan oleh satu atau banyak pakar ke dalam satu area
pengetahuan tertentu sehingga setiap orang dapat menggunakannya untuk memecahkan berbagai
masalah yang spesifik.
Berdasarkan latar belakang tersebut, maka perlu dibangun sebuah aplikasi yang mampu
memberikan informasi diagnosis penyakit batuk. Dimana dengan aplikasi ini diharapkan dapat
membantu masyarakat untuk mengenali gejala-gejala penyakit batuk dan mendapatkan informasi
pengobatan. Selain itu juga memungkinkan setiap individu untuk menghemat waktu, biaya dan
tenaga dalam mendapatkan pelayanan kesehatan.
2
1. 2 Perumusan Masalah
Untuk memperjelas permasalahan yang akan diteliti, maka masalah yang ada perlu
dirumuskan. Adapun rumusan masalah dalam tulisan ini, yaitu Bagaimana membangun aplikasi
sistem pakar tentang diagnosis penyakit batuk.
1. 3 Maksud dan Tujuan
1. 3. 1 Maksud
Berdasarkan permasalahan yang ada, maka maksud dari penulisan ini adalah membangun
Aplikasi Sistem Pakar Diagnosis Penyakit Batuk.
1. 3. 2 Tujuan
Adapun tujuan dari pembangunan aplikasi Sistem Pakar Diagnosis Penyakit Batuk yaitu :
1. Membangun sebuah aplikasi yang dapat membantu seseorang mendiagnosis sendiri penyakit
batuk yang mungkin diderita.
2. Memberikan solusi pengobatan terhadap penyakit yang mungkin diderita oleh pasien tersebut.
3. Untuk memenuhi tugas besar mata kuliah Pemrograman Berorientasi Objek pada jurusan
Teknik Informatika, Universitas Komputer Indonesia.
1. 4 Batasan Masalah
Adapun batasan masalah dalam pembangunan aplikasi ini :
1. Cara akusisi pengetahuan dilakukan dengan pencarian sumber pengetahuan di internet.
2. Metode representasi pengetahuan yang dipilih production rule.
3. Inferensi aturannya mengunakan pelacakan ke depan (forward chaining).
4. Tidak membahas faktor kepastian (certain factor).
5. Aplikasi berbasis desktop.
1. 5 Metodologi Penelitian
1. 5. 1 Metode Pengumpulan Data
Dalam perancangan aplikasi ini, segala bentuk data dan informasi tentang sistem pakar
diagnosis penyakit batuk diperoleh dengan melakukan studi literatur baik berupa buku, artikel
ilmiah, maupun sumber dari internet.
1. 5. 2 Membangunan Perangkat lunak
Teknik analisis data dalam pembuatan perangkat lunak menggunakan paradigma
3
perangkat lunak secara waterfall, yang meliputi beberapa proses seperti pada gambar 1.1.
a. System Analysis
System analysis merupakan tahap menganalisis hal-hal yang diperlukan dalam
pelaksanaan proyek pembuatan perangkat lunak.
b. System Design
System design merupakan tahap penerjemahan dari data yang dianalisis kedalam bentuk
yang mudah dimengerti oleh user.
c. System Coding
System coding merupakan tahap penerjemahan data atau pemecahan masalah yang telah
dirancang keadalam bahasa pemrograman tertentu.
e. System Testing
System testing merupakan tahap pengujian terhadap perangkat lunak yang dibangun.
f. System Maintenance
System maintenance merupakan tahap akhir dimana suatu perangkat lunak yang sudah
selesai dapat mengalami perubahan–perubahan atau penambahan sesuai dengan
permintaan user.
Gambar 1.1 Waterfall
4
1. 6 Sistematika Penulisan
Berikut sistematika penulisan perancangan dan pembangunan aplikasi sistem pakar
diagnosis penyakit batuk :
BAB I PENDAHULUAN
Bab ini menguraikan tentang latar belakang permasalahan, mencoba merumuskan
inti permasalahan yang dihadapi, menentukan tujuan dan kegunaan penelitian, yang kemudian
diikuti dengan metodologi penelitian, pembatasan masalah serta sistematika penulisan.
BAB II LANDASAN TEORI
Berisi pengetahuan dan teori yang mendukung pembangunan aplikasi ini. Seperti
pengetahuan tentang sistem pakar, bahasa pemrograman, serta software database yang
digunakan.
BAB III ANALISIS DAN PERANCANGAN
Bab ini memaparkan analisis kebutuhan perangkat lunak yang digunakan untuk
mendefinisikan hal-hal yang diperlukan dalam pengembangan perangkat lunak. Hasil dari
analisis kebutuhan tersebut kemudian dilanjutkan dengan perancangan perangkat
lunak. Analisis dan perancangan laporan ini meliputi spesifikasi perangkat lunak, analisis
kebutuhan perangkat lunak dan perancangan perangkat lunak.
BAB IV IMPLEMENTASI
Bab ini menjelaskan implementasi dari perangkat lunak yang dibangun.
Implementasi perangkat lunak dilakukan berdasarkan kebutuhan analisis dan perancangan
perangkat lunak yang sudah dilakukan. Dari hasil implementasi kemudian dilakukan
pengujian perangkat lunak yang didasarkan pada analisis kebutuhan perangkat lunak.
BAB V KESIMPULAN DAN SARAN
Membahas mengenai kesimpulan yang dirumuskan dari hasil pembahasan bab-bab
sebelumnya serta saran yang merupakan tindak lanjut dari kesimpulan yang berupa
rekomendasi yang diperlukan untuk pembangunan sistem selanjutnya.
5
BAB 2
LANDASAN TEORI
2. 1 Sistem Pakar
Sistem Pakar (Expert System) adalah usaha untuk menirukan seorang pakar. Biasanya
Sistem Pakar berupa perangkat lunak pengambil keputusan yang mampu mencapai tingkat
performa yang sebanding seorang pakar dalam bidang problem yang khusus dan sempit. Ide
dasarnya adalah kepakaran ditransfer dari seorang pakar (atau sumber kepakaran yang lain) ke
komputer, pengetahuan yang ada disimpan dalam komputer, dan pengguna dapat berkonsultasi
pada komputer itu untuk suatu nasehat, lalu komputer dapat mengambil inferensi
(menyimpulkan, mendeduksi, dll.) seperti layaknya seorang pakar kemudian menjelaskannya ke
pengguna tersebut, bila perlu dengan alasan-alasannya. Sistem Pakar malahan terkadang lebih
baik unjuk kerjanya daripada seorang pakar manusia!
Kepakaran (expertise) adalah pengetahuan yang ekstensif (meluas) dan spesifik yang
diperoleh melalui rangkaian pelatihan, membaca, dan pengalaman. Pengetahuan membuat pakar
dapat mengambil keputusan secara lebih baik dan lebih cepat daripada nonpakar dalam
memecahkan problem yang kompleks. Kepakaran mempunyai sifat berjenjang, pakar top
memiliki pengetahuan lebih banyak daripada pakar junior.
Tujuan Sistem Pakar adalah untuk mentransfer kepakaran dari seorang pakar ke komputer,
kemudian ke orang lain (yang bukan pakar). Proses ini tercakup dalam rekayasa pengetahuan
(knowledge engineering) yang akan dibahas kemudian.
2. 1. 1 Manfaat sistem pakar.
Mengapa Sistem Pakar menjadi sangat populer? Hal ini disebabkan oleh sangat banyaknya
kemampuan dan manfaat yang diberikan oleh Sistem Pakar, di antaranya:
a) Meningkatkan output dan produktivitas, karena Sistem Pakar dapat bekerja lebih cepat
dari manusia.
b) Meningkatkan kualitas, dengan memberi nasehat yang konsisten dan mengurangi
kesalahan.
c) Mampu menangkap kepakaran yang sangat terbatas.
d) Dapat beroperasi di lingkungan yang berbahaya.
e) Memudahkan akses ke pengetahuan.
f) Handal. Sistem Pakar tidak pernah menjadi bosan dan kelelahan atau sakit. Sistem Pakar
juga secara konsisten melihat semua detil dan tidak akan melewatkan informasi yang
relevan dan solusi yang potensial.
6
g) Meningkatkan kapabilitas sistem terkomputerisasi yang lain. Integrasi Sistem Pakar
dengan sistem komputer lain membuat lebih efektif dan mencakup lebih banyak
aplikasi.
h) Mampu bekerja dengan informasi yang tidak lengkap atau tidak pasti. Berbeda dengan
sistem komputer konvensional, Sistem Pakar dapat bekerja dengan inofrmasi yang tidak
lengkap. Pengguna dapat merespon dengan: “tidak tahu” atau “tidak yakin” pada satu
atau lebih pertanyaan selama konsultasi, dan Sistem Pakar tetap akan memberikan
jawabannya.
i) Mampu menyediakan pelatihan. Pengguna pemula yang bekerja dengan Sistem Pakar
akan menjadi lebih berpengalaman. Fasilitas penjelas dapat berfungsi sebagai guru.
j) Meningkatkan kemampuan problem solving, karena mengambil sumber pengetahuan dari
banyak pakar.
k) Meniadakan kebutuhan perangkat yang mahal.
l) Fleksibel.
2. 1. 2 Keterbatasan sistem pakar
Metodologi Sistem Pakar yang ada tidak selalu mudah, sederhana dan efektif. Berikut
adalah keterbatasan yang menghambat perkembangan Sistem Pakar:
a) Pengetahuan yang hendak diambil tidak selalu tersedia.
b) Kepakaran sangat sulit diekstrak dari manusia.
c) Pendekatan oleh setiap pakar untuk suatu situasi atau problem bisa berbeda-beda,
meskipun sama-sama benar.
d) Adalah sangat sulit bagi seorang pakar untuk mengabstraksi atau menjelaskan langkah
mereka dalam menangani masalah
e) Pengguna Sistem Pakar mempunyai batas kognitif alami, sehingga mungkin tidak bisa
memanfaatkan sistem secara maksimal.
f) Sistem Pakar bekerja baik untuk suatu bidang yang sempit.
g) Banyak pakar yang tidak mempunyai jalan untuk mengecek apakah kesimpulan mereka
benar dan masuk akal.
h) Istilah dan jargon yang dipakai oleh pakar dalam mengekspresikan fakta seringkali
terbatas dan tidak mudah dimengerti oleh orang lain.
i) Pengembangan Sistem Pakar seringkali membutuhkan perekayasa pengetahuan
(knowledge engineer) yang langka dan mahal.
j) Kurangnya rasa percaya pengguna menghalangi pemakaian Sistem Pakar.
k) Transfer pengetahuan dapat bersifat subyektif dan bias.
7
2. 1. 3 Komponen sistem pakar
Secara umum, Sistem Pakar biasanya terdiri atas beberapa komponen yang masing-masing
berhubungan seperti terlihat pada Gambar II-1.
Basis Pengetahuan, berisi pengetahuan yang dibutuhkan untuk memahami, memformulasi,
dan memecahkan masalah. Basis pengetahuan tersusun atas 2 elemen dasar:
a) Fakta, misalnya: situasi, kondisi, dan kenyataan dari permasalahan yang ada, serta teori dalam
bidang itu.
b) Aturan, yang mengarahkan penggunaan pengetahuan untuk memecahkan masalah yang
spesifik dalam bidang yang khusus
Mesin Inferensi (Inference Engine), merupakan otak dari Sistem Pakar. Juga dikenal sebagai
penerjemah aturan (rule interpreter). Komponen ini berupa program komputer yang
menyediakan suatu metodologi untuk memikirkan (reasoning) dan memformulasi kesimpulan.
Kerja mesin inferensi meliputi:
a. Menentukan aturan mana akan dipakai.
b. Menyajikan pertanyaan kepada pemakai, ketika diperlukan.
c. Menambahkan jawaban ke dalam memori Sistem Pakar.
d. Menyimpulkan fakta baru dari sebuah aturan
e. Menambahkan fakta tadi ke dalam memori.
Gambar 2.1 Struktur skematis sebuah Sistem Pakar.
Papan Tulis (Blackboard/Workplace), adalah memori/lokasi untuk bekerja dan menyimpan
hasil sementara. Biasanya berupa sebuah basis data.
8
Antarmuka Pemakai (User Interface). Sistem Pakar mengatur komunikasi antara pengguna
dan komputer. Komunikasi ini paling baik berupa bahasa alami, biasanya disajikan dalam bentuk
tanya jawab dan kadang ditampilkan dalam bentuk gambar/grafik. Antarmuka yang lebih
canggih dilengkapi dengan percakapan (voice communication).
Subsistem Penjelasan (Explanation Facility). Kemampuan untuk menjejak (tracing)
bagaimana suatu kesimpulan dapat diambil merupakan hal yang sangat penting untuk transfer
pengetahuan dan pemecahan masalah. Komponen subsistem penjelasan harus dapat
menyediakannya yang secara interaktif menjawab pertanyaan pengguna, misalnya:
1. “Mengapa pertanyaan tersebut anda tanyakan?”
2. “Seberapa yakin kesimpulan tersebut diambil?”
3. “Mengapa alternatif tersebut ditolak?”
4. “Apa yang akan dilakukan untuk mengambil suatu kesimpulan?”
5. “Fakta apalagi yang diperlukan untuk mengambil kesimpulan akhir?”
Sistem Penghalusan Pengetahuan (Knowledge Refining System). Seorang pakar mempunyai
sistem penghalusan pengetahuan, artinya mereka bisa menganalisis sendiri performa mereka,
belajar dari pengalaman, serta meningkatkan pengetahuannya untuk konsultasi berikutnya. Pada
Sistem Pakar, swaevaluasi ini penting sehingga dapat menganalisis alasan keberhasilan atau
kegagalan pengambilan kesimpulan, serta memperbaiki basis pengetahuannya.
2. 2 UML (Unified Modeling language)
2. 2. 1 Sejarah Singkat UML
UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar
untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah
sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan
standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-
kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang
diperlukan dalam sistem software (http://www.omg.org).
Pendekatan analisis dan rancangan dengan menggunakan model OO mulai diperkenalkan
sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah
meningkat dan mulai komplek. Jumlah yang menggunakaan metoda OO mulai diuji cobakandan
diaplikasikan antara 1989 hingga 1994, seperti halnya oleh Grady Booch dari Rational Software
Co., dikenal dengan OOSE (Object-Oriented Software Engineering), serta James Rumbaugh dari
General Electric, dikenal dengan OMT (Object Modelling Technique). Kelemahan saat itu
disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang
9
berbasis OO, ketika mereka bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai
mendiskusikan untuk mengadopsi masing-masing pendekatan metoda OO untuk membuat suatu
model bahasa yang uniform / seragam yang disebut UML (Unified Modeling Language) dan
dapat digunakan oleh seluruh dunia.
Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Rumbaugh bergabung
Booch untuk membuat sebuah project pendekatan metoda yang uniform/seragam dari masing-
masing metoda mereka. Saat itu baru dikembangkan draft metoda UML version 0.8 dan
diselesaikan serta di release pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson
bergabung dan UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga
muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version
1.3 telah diperkaya dan direspons oleh OMG (Object Management Group), Anderson
Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll serta di pelihara oleh OMG
yang dipimpin oleh Cris Kobryn. UML adalah standar dunia yang dibuat oleh Object
Management Group (OMG), sebuah badan yang bertugas mengeluarkan standar-standar
teknologi object-oriented dan software component.
2. 2. 2 Pengenalan UML
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata
dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah sebuah bahasa
yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta secara fisik
mempresentasikan dari sebuah sistem. Seperti halnya UML adalah sebuah bahasa standard untuk
pengembangan sebuah software yang dapat menyampaikan bagaimana membuat dan membentuk
model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat yang
merupakan salah satu proses implementasi pengembangan software. UML tidak hanya
merupakan sebuah bahasa pemograman visual saja, namun juga dapat secara langsung
dihubungkan ke berbagai bahasa pemograman, seperti JAVA, C++, Visual Basic, atau bahkan
dihubungkan secara langsung ke dalam sebuah object-oriented database. Begitu juga mengenai
pendokumentasian dapat dilakukan seperti; requirements, arsitektur, design, source code,
project plan, tests, dan prototypes.
Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah bahasa model, dan
mempelajari 3 (tiga) elemen utama dari UML seperti building block, aturan-aturan yang
menyatakan bagaimana building block diletakkan secara bersamaan, dan beberapa mekanisme
umum (common).
Building block
Tiga macam yang terdapat dalam building block adalah katagori benda/Things, hubungan,
dan diagram. Benda/things adalah abstraksi yang pertama dalam sebuah model, hubungan
10
sebagai alat komunikasi dari benda-benda, dan diagram sebagai kumpulan / group dari benda-
benda/things.
Benda/Things
Adalah hal yang sangat mendasar dalam model UML, juga merupakan bagian paling statik
dari sebuah model, serta menjelaskan elemen-elemen lainnya dari sebuah konsep dan atau
fisik. Bentuk dari beberapa benda/thins adalah sebagai berikut:
Pertama, adalah sebuah kelas yang diuraikan sebagai sekelompok dari object yang
mempunyai atribute, operasi, hubungan yang semantik. Sebuah kelas mengimplementasikan
1 atau lebih interfaces. Sebuah kelas dapat digambarkan
sebagai sebuah persegi panjang, yang mempunyai sebuah nama, atribute, dan metoda
pengoperasiannya, seperti terlihat dalam berikut :
Gambar 2.2 Sebuah Kelas dari model UML
Kedua, yang menggambarkan ‘interface’ merupakan sebuah antar-muka yang
menghubungkan dan melayani antar kelas dan atau elemen. ‘Interface’/antar-
mukamendefinisikan sebuah set / kelompok dari spesifikasi pengoperasian, umumnya
digambarkan dengan sebuah lingkaran yang disertai dengan namanya. Sebuah antar-muka
berdiri sendiri dan umumnya merupakan pelengkap dari kelas atau komponen, seperti dalam
gambar berikut :
Gambar 2.3 Sebuah interface/antar-muka
Ketiga, adalah collaboration yang didefinisikan dengan interaksi dan sebuah kumpulan /
kelompok dari kelas-kelas/elemen-elemen yang bekerja secara bersama-sama. Collaborations
mempunyai struktura dan dimensi. Pemberian sebuah kelas memungkinkan berpartisipasi
11
didalam beberapa collaborations dan digambarkan dengan sebuah ‘elips’ dengan garis
terpotong-potong
Gambar 2.4 Collaborations
Keempat, sebuah ‘use case’ adalah rangkaian/uraian sekelompok yang saling terkait dan
membentuk sistem secara teratur yang dilakukan atau diawasi oleh sebuah aktor. ‘use case’
digunakan untuk membentuk tingkah-laku benda/ things dalam sebuah model serta di
realisasikan oleh sebuah collaboration. Umumnya ‘use case’ digambarkan dengan sebuah
‘elips’ dengan garis yang solid, biasanya mengandung nama, seperti terlihat dalam gambar
berikut :
Gambar 2.5 Use Case
Kelima, sebuah node merupakan fisik dari elemen-elemen yang ada pada saat dijalankannya
sebuah sistem, contohnya adalaha sebuah komputer, umumnya mempunyai sedikitnya
memory dan processor. Sekelompok komponen mungkin terletak pada sebuah node dan juga
mungkin akan berpindah dari node satu ke node lainnya. Umumnya node ini digambarkan
seperti kubus serta hanya mengandung namanya, seperti terlihat dalam gambar berikut :
Gambar 2.6 Nodes
Hubungan / Relationship
Ada 4 macam hubungan didalam penggunaan UML, yaitu; dependency, association,
generalization, dan realization. Pertama, sebuah dependency adalah hubungan semantik
12
antara dua benda/things yang mana sebuah benda berubah mengakibatkan benda satunya akan
berubah pula. Umumnya sebuah dependency digambarkan sebuah panah dengan garis
terputus-putus seperti terlihat dalam gambar berikut :
Gambar 2.7 Dependency
Kedua, sebuah association adalah hubungan antar benda struktural yang terhubung diantara
obyek. Kesatuan obyek yang terhubung merupakan hubungan khusus, yang menggambarkan
sebuah hubungan struktural diantara seluruh atau sebagian. Umumnya assosiation
digambarkan dengan sebuah garis yang dilengkapi dengan sebuah label, nama, dan status
hubungannya seperti terliahat dalam gambar berikut :
Gambar 2.8 Association
Ketiga, sebuah generalization adalah menggambarkan hubungan khusus dalam obyek
anak/child yang menggantikan obyek parent / induk . Dalam hal ini, obyek anak memberikan
pengaruhnya dalam hal struktur dan tingkah lakunya kepada obyek induk. Digambarkan
dengan garis panah seperti terlihat dalam gambar berikut :
Gambar 2.9 Generalizations
Keempat, sebuah realization merupakan hubungan semantik antara pengelompokkan yang
menjamin adanya ikatan diantaranya. Hubungan ini dapat diwujudkan diantara interface dan
kelas atau elements, serta antara use cases dan collaborations. Model dari sebuah hubungan
realization seperti terlihat dalam gambar berikut :
Gambar 2.10 Realizations
Diagram
UML sendiri terdiri atas pengelompokkan diagram-diagram sistem menurut aspek atau sudut
pandang tertentu. Diagram adalah yang menggambarkan permasalahan maupun solusi dari
permasalahan suatu model. UML mempunyai 9 diagram, yaitu; use case, class, object, state,
sequence, collaboration, activity, component, dan deployment diagram.
13
2. 2. 3 Diagram UML
2. 2. 3. 1 Use Case
Use case adalah suatu diagram yang membantu pengembangan sistem bekerja dengan user
untuk menentukan kegunaan sistem. Koleksi dari use case melukiskan apa yang diinginkan user
terhadap sebuah sistem. Use case bertujuan untuk menentukan bagaimana actors berinteraksi
dengan sebuah sistem.
a. Actor
Proses pembuatan Use case diawali dengan mengidentifikasi aktor pada sistem. Aktor adalah
segala sesuatu yang berhubungan dengan sistem sebagai pelaksana atau pemucu timbulnya use
case. Aktor dapat berupa manusia, perangkat lunak, perangkat keras data store, ataupun
jaringan. Setiap aktor mempunyai peranan tertentu.
b. Precondition
Precondition adalah sebuah kondisi awal yang harus dimiliki aktor untuk dapat masuk kedalam
sistem. Precondition memberitahukan bahwa sistem harus berada dalam kondisi apa pada awal
use case.
c. Postcondition
Postcondition adalah sebuah kondisi akhir dari proses use case yang telah dilakukan
atau hasil akhir yang diterima oleh actor. Postcondition memberitahukan bahwa sistem
harus berada dalam kondisi apa pada akhir use case.
d. Flow of event
Flow of event adalah sebuah skenario yang ditulis dengan anggapan bahwa segala
sesuatunya berjalan dengan lancar pada sebuah proses. Skenario ditulis dari sudut
pandang aktor. Setiap skenario merupakan serangkaian kejadian yang mendeskripsikan
kegunaan dari use case.
e. Alternative flow
Alternative flow adalah sebuah skenario yang memberikan serangkaian kejadian yang
berbeda dengan yang digunakan pada flow of event. Di sini, seorang aktor mungkin
memilih salah satu dari beberapa hal yang dapat dilakukan pada point yang sama dalam use
case.
14
Table 2.1 Use Case Diagram
No Simbol Keterangan
1.AktorMenunjukkan user yang akan menggunakansistem
2. UsecaseMenunjukkan proses yang terjadi pada sistem
3.Undirectional AssociationMenunjukkan hubungan antara aktor dengandan use case atau antar use case
2. 2. 3. 2 Activity Diagram
Activity diagram adalah bagian dari UML yang digunakan untuk menggambarkan
tahapan dari setiap proses bisnis yang ada agar lebih mudah memahami proses bisinis
yang terjadi.
Dalam activity diagram tiap aktivitas direpresentasikan dengan rounded rectangle
yang dihubungkan dengan anak panah untuk menggambarkan transisi dari satu
aktivitas ke aktivitas lain. Activity diagram dimulai dari initial state dan diakhiri dengan final
state.
Table 2.2 Activity Diagram
No Simbol Keterangan
1.Kondisi AwalMenunjukkan awal dari suatu diagramaktivitas
2.Kondisi AkhirMenunjukkan akhir dari suatu diagramaktivitas
3. Kondisi transisiMenunjukkan kondisi transisi antar aktivitas
4.SwimlaneMenunjukkan aktor dari diagram aktivitasyang dibuat
5.AktivitasMenunjukkan aktivitas-aktivitas yang terdapatpada diagram aktivitas
6.Pengecekan kondisiMenunjukkan pengecekan terhadap suatukondisi
15
2. 2. 3. 3 Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem
(termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap
waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-
objek yang terkait).
Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian
langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output
tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja
yang terjadi secara internal dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message
digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase
desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation
bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya
sebuah message.
Table 2.3 Sequence Diagram
No Simbol Keterangan
1.ObjekMenunjukkan objek yang yang terdapat didiagram sequence
2.
3.
Pesan objekMenunjukkan pesan yang disampaikan keobjeklain dalam diagram sequence
2. 2. 3. 4 Class Diagram
Class diagram adalah bagian dari UML yang menggambarkan sebuah kumpulan dari kelas-
kelas yang ada dan hubungan diantara kelas tersebut dimana setiap kelas mempunyai attributes
dan operations.
Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan
layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Selain itu, class
diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan
satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
16
No Simbol Keterangan
1.
2.
3.
2. 2. 3. 5 Statechart Diagram
Statechart diagram adalah bagian dari UML yang menggambarkan tingkah laku yang
umum dari sebuah objek didalam sebuah class yang spesifik dan berisi states dan transisi
diantaranya.
Statechart sangat penting karena dapat membantu analisis sistem, designer dan
pengembangan dalam memahami behavior dari objek dalam suatu sistem.
2. 2. 3. 6 Collaboration Diagram
Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence
diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu
penyampaian message. Setiap message memiliki sequence number, dimana message dari
level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.
2. 2. 3. 7 Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen
piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti
lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library
maupun executable, baik yang muncul pada compile time, link time, maupun run time.
Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari
komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu
kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
2. 2. 3. 8 Deployment Diagram
Deployment/physical diagram menggambarkan detail bagaimana komponen dalam
infrastruktur sistem, dimana komponen akan terletak (pada mesin, server atau piranti keras
apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain
yang bersifat fisikal.
17
Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk
menyebarkan komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya
TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.
2. 2. 3. 9 Object Diagram
Object diagram adalah diagram yang memberikan gambaran model instance-instance dari
sebuah class. Diagram ini digunakan untuk menggambarkan sebuah sistem pada sebuah
sudut pandang waktu tertentu. Dengan menggunakan diagram ini anda dapat memeriksa
keabsahan kelas-kelas diagram berikut aturan-aturan multiplisitasnya dengan “real data” dan
mengujinya dengan skenario-skenario tertentu.
2. 3 JAVA
2. 3. 1 Seajarah Singkat JAVA
Pada tahun 1991, sekelompok insinyur SUN yang dipimpin Patrick Naughton dan James
Gosling ingin merancang bahasa komputer untuk perangkat consumer seperti cable Tv box.
Karena perangkat itu tidak mempunyai banyak memori, bahasa harus berukuran kecil dan
menghasilkan kode yang liat, maka bahasa harus bebas dari arsitektur manapun. Proyek ini diberi
nama kode Green.
Kebutuhan kecil, liat dan kode netral terhadap platform mengantar tim mempelajari
implementasi Pascal yang pernah dicoba. Niklaus Wirth, pencipta bahasa Pascal telah merancang
bahasa portable yang menghasilkan kode antara untuk mesin hipotesis.
Karena orang-orang di proyek Green berbasis C++ bukan pascal maka kebanyakan sintaks
di ambil dari C++, serta mengadopsi orientasi objek bukan procedural. Produk pertama proyek
Green adalah “*7”, sebuah kendali jauh yang sangat cerdas.
Pada tahun 1995, Netscape memutuskan membuat browser yang dilengkapi dengan Java.
Setelah itu diikuti IBM, Symantec, Inspire, bahkan Microsoft. Bahasa Java merupakan karya Sun
Microsystem Inc. Rilis resmi dilakukan pada Nopember 1995. Maskot Java adalah Duke. Dua
bulan berikutnya Netscape menjadi perusahaan pertama yang memperoleh lisensi bahasa Java
dari Sun.
Pada tahun 1996, Sun mengeluarkan JSDK (Java Software Development Kit), kemudian
secara berturut-turut:
ƒ Versi1.02
ƒ Versi 1.1
ƒ Versi 1.2
ƒ Versi 1.3
ƒ Versi 1.4
18
Java telah berkembang dari semula ditujukan untuk pemrograman applet yang berjalan di
web browser menjadi bahasa pemrograman kelas dunia untuk pengembangan aneka ragam
aplikasi komputer yang berjalan di bermacam-macam perangkat mulai dari handheld devices
seperti, handphone, PDA (Personal Digital Assistant) sampai aplikasi tersebar skala enterprise
di beragam komputer server. Java adalah bahasa berorientasi objek yang dapat digunakan untuk
pengembangan aplikasi mandiri, aplikasi berbasis internet maupun intranet, serta aplikasi untuk
perangkat-perangkat cerdas yang dapat berkomunikasi lewat internet atau jaringan komunikasi.
2. 3. 2 Pengenalan JAVA
Dalam Java ada 2 jenis program berbeda, yaitu aplikasi dan applet. Keduanya merupakan
bagian dari execute, dimana execute merupakan salah satu fase kelima dalam siklus program
Java. Aplikasi adalah program yang biasanya disimpan dan di eksekusi dari komputer lokal.
Applet adalah program yang biasanya disimpan pada komputer yang jauh,yang dikoneksikan
pemakai lewat web browser. Komputer jauh menjalakan web server yang memberi layanan
terhadap permintaan web browser.
Kebanyakan bahasa pemrograman modern berdiri di atas pustaka-pustaka kelas yang telah
ada untuk mendukung fungsionalitas bahasanya. Pada bahasa Java, kelompok-kelompok kelas
yang berkaitan erat dimasukkan dalam satu paket, bervariasi sesuai edisi Java.
Java adalah bahasa yang dapat dijalankan dimanapun dan di sembarang platform apapun, di
beragam lingkungan: Internet, intranets, consumer electronic products, dan computer
applications. Untuk beragam aplikasi yang dibuat dengan bahasa Java, Java dipaketkan dalam
edisi-edisi berikut:
1. Java 2 Standar Edition (J2SE), J2SE menyediakan lingkungan pengembangan yang kaya
fitur, stabil, aman, dan cross-platform. Edisi ini mendukung konektivitas basis data,
rancangan user interface, masukkan/ keluaran (input/ output), dan pemrograman jaringan
(network programming), dan termasuk sebagai paket-paket dasar bahasa Java.
2. Java 2 Enterpise Edition (J2EE), J2EE menyediakan tempat untuk membangun dan
menjalankan multitier enterprise editions. J2EE berisi paket-paket di J2SE ditambah paket-
paket untuk mendukung pengembangan Enterprise JavaBeans, Java Servlets, JavaServer
Pages, XML, dan kendali transaksi yang fleksibel.
3. Java 2 Micro Edition (J2ME), J2ME selain menyedikan bahasa Java yang sama, unggul
dalam portabilitas (kemampuan dapat dijalankan dimanapun), safe network delivery, seperti
J2SE dan J2EE. Aplikasi-aplikasi dapat diskala-kan (dimampukan) agar dapat bekerja dengan
J2SE dan J2EE. J2ME adalah untuk beragam consumer electronic product, seperti pager,
smart card, cell phone, handheld PDA, dan set-top box.
Ada 3 kombinasi kunci yang membuat Java menjadi teknologi yang secara fundamental
berbeda dari yang lain, yang ada saat ini. Pertama, semua orang dapat menggunakan applet
19
yang kecil, aman, dinamik, lintas-platform, aktif, dan siap dijalankan di jaringan sejak awal.
Kedua, Java adalah bahasa pemrograman yang ampuh, memiliki kekuatan desain berorientasi
objek dengan sintaks yang sederhana dan mudah dikenal. Ketiga, Java adalah kumpulan class
object yang ampuh, yang melayani programmer dengan uraian yang jelas untuk banyak fungsi
sistem umum, seperti pembuatan window, penggunaan jaringan, dan input/ output.
2. 3. 3 Beberapa Fitur-fitur Penting Dalam Bahasa Java
• Bahasa sederhana
Java dirancang untuk mudah dipelajari dan digunakan dengan secara efektif. Java tidak
mendukung fitur-fitur rumit seperti:
1. Explicit pointer manipulation
2. Implicit type casting
3. Structures atau union
4. Operator overloading
5. Templates
6. Header files
7. Multiple inheritance
Rancangan bahasa Java telah berdasar teknologi yang telah terbukti dan dikembangkan di
bahasa-bahasa pemrograman lainnya.
Bahasa berorientasi objek
Java bukan turunan langsung dari bahasa pemrograman manapun, juga sama sekali tidak
kompatibel dengan semuanya. Model objek Java adalah sederhana dan mudah dikembangkan,
namun sejalan dengan itu, nilangan dan tipe data sederhana lain dianggap sebagai non-objek
berkinerja tinggi.
OOP (Object Oriented Programming) adalah cara ampuh dalam pengorganisasian dan
pengembangan perangkat lunak. Pada OOP, program komputer sebagai sekelompok objek yang
saling berinteraksi. Objek-objek ini ada secara secara independent yang mempunyai aturan-
aturan berkomunikasi dengan objek lain dan untuk memerinthakan objek lain guna meminta
informasi tertentu atau meminta objek lain mengerjakan sesuatu.
• Bahasa statically typed
Semua objek dideklarasikan terlebih dahulu sebelum digunakan. Melalui fitur ini kode
program lebih dapat dioptmasi untuk menghasilkan program berkinerja tinggi.
• Bahasa dikompilasi
Sebelum menjalankan program di bahasa Java, program dikompilasi menggunakan Java
Compiler. Kompilais akan menghasilkan file “bytecode” yang serupa fungsinya dengan file kode
mesin. Program “bytecode” yang dihasilkan dapat di eksekusi di sembarang Java Interpreter.
20
Java Interpreter membaca file “bytecode” dan menterjemahkan perintah “bytecode” menjadi
perintah-perintah bahasa mesin yang dapat di eksekusi mesin.
• Bahasa yang aman
Java menggunakan model pengamanan 3 lapis untuk melindungi sistem dari Untrusted Java
Code.
1. Bytecode verifier membaca bytecode sebelum dijalankan dan menjamin bytecode
memenuhi aturan-aturan dasar bahasa Java
2. Class loader menangani pemuatan kelas Java ke runtime interpreter.
3. Manajer keamanan menangani keamanan tingkat aplikasi dengan mengendalikan apakah
program berhak mengakses sumber daya seperti sistem file, port jaringan, proses
eksternal dan sistem windowing.
Selain itu Java menyediakan beragam teknik pengaman, yaitu:
1. Bahasa dirancang untuk mempersulit eksekusi kode perusak
2. Program Java dikompilasi menajdi serangkaian bytecode.
3. Java mempunyai pengamanan terhadap applet.
• Bahasa indpenden terhadap platform
Platform independence merupakan kemampuan program bekerja di sistem operasi atau
sistem komputer berbeda. Bahasa Java adalah bahasa yang secara sempurna tidak bergantung
platform.
• Bahasa multithreading
Thread adalah menyatakan program komputer melakukan lebih dari satu tugas di satu
waktu yang sama. Java menyediakan kakas untuk menulis program multithread, program
mempunyai lebih dari 1 thread eksekusi pada saat yang sama sehingga memungkinkan program
menagani beberapa tugas secara konkuren.
• Bahasa yang didukung garbage collector
Artinya, program tidak perlu menghapus sendiri objek-objek yang tidak digunakan lagi.
Fasilitas ini mengurangi beban pengelolaan memori oleh pemrogram dan mengurangi atau
mengeliminasi sumber kesalahan terbesar yang terdapat di bahasa yang memungkinkanalokasi
dinamis.
• Bahasa yang tegar
Java interpreter memeriksa semua akses sistem yang dilakukan. Program java tidak dapat
menyebabkan crash terhadap sistem. Java mempunyai mekanisme exception handling yang
ampuh. Exception handling menyediakan cara untuk memisahkan antara bagian penanganan
kesalahan dengan bagian kode normal sehingga menuntun ke struktur kode program yang lebih
bersih dan menjadikan aplikasi lebih tegar.
21
2. 3. 4 Token
Dalam Java ada yang dikenal dengan istilah token. Token merupakan elemen terkecil di
program yang mempunyai arti bagi kompilator. Kompilator bertugas membaca karakter-karakter
di kode sumber dan menerapkan aturan-aturan secara progresif menjadi potongan lebih besar
seperti identifier, ekspresi, kalimat, dan kelas.
Token Java dibagi 5, yaitu:
a. Identifier
b. Keyword
c. Literal
d. Operator
e. Separator
a. Identifier
Identifier adalah token yang merepresentasikan nama. Dalam Java, identifier adalah nama
yang diberikan untuk variable, class, atau method. Identifier boleh dimulai dengan huruf,
underscore (_) atau tanda dollar ($). Identifier adalah case sensitive (membedakan huruf besar/
kecil) dan tidak ada batas maksimum.
Contoh : username
user_name
_sys_var1
$change
b. Keyword
Keyword (kata kunci) adalah identifier yang digunakan dalam Java untuk suatu tujuan
khusus. Daftar keyword Java sebagai berikut:
abstract, Boolean, Break, Byte, byvalue, Case, Catch, Char, Class, Const, continue, default, Do,
double, else, extends, false, final, finally, float, for, goto, if, implements, import, instanceof, In,
Interface, Long, Native, New, Null, Package, private, protected, public, return, short, static,
Super, Switch, synchronized, This, threadsafe, throwm Transient, True, Try, Void, while.
c. Literal
Penulisan besaran untuk variabel adalah penting, literal Java terdiri dari angka, karakter, dan
string. Angka terdiri dari bilangan bulat (integer), bilangan mengambang (floating point), dan
boolean. Nilai boolean untuk true dan false direpresentasikan sebagai 1 dan 0.
d. Operator
Operator menspesifikasikan evaluasi atau komputasi terhadap objek. Operan yang
dioperasikan dapat berupa literal, variabel, atau nilai yang dikirim oleh metode atau fungsi.
e. Separator (Pemisah)
22
Separator digunakan untuk menginformasikan ke komplator Java mengenai adanya pengelompokkan di kode program. Berikut daftar separator yang digunakan dalam Java
2. 3. 5 Struktur Program JAVA
Penulisan program Java dapat dilakukan pada semua teks editor yang paling disukai baik itu
editor handal semacam eclipse dan netbeans ataupun editor simpel seperti editplus, dan
crimson. Dalam pembuatan program java yang harus diperhatikan dalam pembuatan program
java adalah penulisan huruf besar dan kecil karena java memiliki sifat Case Sensitive. Berikut
adalah bentuk umum dari penulisan program Java:
Pertama dalam program Java minimal terdapat sebuah class, dimana nama dari class
tersebut diusahakan sama dengan nama file Java (arti dari class akan dijelaskan pada pertemuan
selanjutnya), dan setiap class harus dibuka dengan tanda ‘{‘ dan ditutup dengan tanda ‘}’.
Contoh: class bow{
(isi dari class)
}
Selanjutnya faktor utama lainnya yang wajib dimiliki dari sebuah program Java adalah harus
memilik sebuah fungsi utama main(). Fungsi dari main() adalah dijadikan sebagai awal
Table 2.4 Daftar Separator
23
pengeksekusian aplikasi Java, kode (code) yang terdapat pada metode inilah yang akan
dieksekusi pertama kali.
Contoh: class bow{
public static void main(String[] args)
{
(tulis code/ program disini)
}
}
Metode main () didefinisikan sebagai public static void, berikut penjelasannya
public, berarti metode ini dapat dipanggil dari luar class
static, menunjukkan metode ini bersifat sama untuk semua class
void, berarti metode ini tidak mengembalikan nilai.
Argument args [] adalah array objek string argument baris-baris perintah yang dilewatkan
ke kelas yang di eksekusi.
Didalam penulisan program Java kita dapat membuat sebuah komentar, ada dua jenis tipe
komentar pada Java, yang pertama menggunakan pasangan simbol /* dan */. Semua tulisan yang
berada dalam tanda tersebut akan diperlakukan sebagai komentar. Yang kedua menggunakan
awalan simbol ‘//’, jadi semua tulisan sesudah tanda ini dan berada pada baris yang sama
dianggap komentar.
2. 4 MySQL
2. 4. 1 Sistem Manajemen Basis Data Relasional
MySQL adalah sebuah implementasi dari sistem manajemen basisdata relasional (RDBMS)
yang didistribusikan secara gratis dibawah lisensi GPL (General Public License). Setiap
pengguna dapat secara bebas menggunakan MySQL, namun dengan batasan perangkat lunak
tersebut tidak boleh dijadikan produk turunan yang bersifat komersial. MySQL sebenarnya
merupakan turunan salah satu konsep utama dalam basisdata yang telah ada sebelumnya; SQL
(Structured Query Language). SQL adalah sebuah konsep pengoperasian basisdata, terutama
untuk pemilihan atau seleksi dan pemasukan data, yang memungkinkan pengoperasian data
dikerjakan dengan mudah secara otomatis.
Kehandalan suatu sistem basisdata (DBMS) dapat diketahui dari cara kerja pengoptimasi-
nya dalam melakukan proses perintah-perintah SQL yang dibuat oleh pengguna maupun
program-program aplikasi yang memanfaatkannya. Sebagai peladen basis data, MySQL
mendukung operasi basisdata transaksional maupun operasi basisdata nontransaksional. Pada
modus operasi nontransaksional, MySQL dapat dikatakan unggul dalam hal unjuk kerja
dibandingkan perangkat lunak peladen basisdata kompetitor lainnya. Namun demikian pada
24
modus nontransaksional tidak ada jaminan atas reliabilitas terhadap data yang tersimpan,
karenanya modus nontransaksional hanya cocok untuk jenis aplikasi yang tidak membutuhkan
reliabilitas data seperti aplikasi blogging berbasis web (wordpress), CMS, dan sejenisnya. Untuk
kebutuhan sistem yang ditujukan untuk bisnis sangat disarankan untuk menggunakan modus
basisdata transaksional, hanya saja sebagai konsekuensinya unjuk kerja MySQL pada modus
transaksional tidak secepat unjuk kerja pada modus nontransaksional.
2. 4. 2 Keistimewaan MySQL
MySQL memiliki beberapa keistimewaan, antara lain :
1. Portabilitas. MySQL dapat berjalan stabil pada berbagai sistem operasi seperti Windows,
Linux, FreeBSD, Mac Os X Server, Solaris, Amiga, dan masih banyak lagi.
2. Perangkat lunak sumber terbuka. MySQL didistribusikan sebagai perangkat lunak sumber
terbuka, dibawah lisensi GPL sehingga dapat digunakan secara gratis.
3. Multiuser. MySQL dapat digunakan oleh beberapa pengguna dalam waktu yang bersamaan
tanpa mengalami masalah atau konflik.
4. 'Performance tuning', MySQL memiliki kecepatan yang menakjubkan dalam menangani
query sederhana, dengan kata lain dapat memproses lebih banyak SQL per satuan waktu.
5. Ragam tipe data. MySQL memiliki ragam tipe data yang sangat kaya, seperti signed /
unsigned integer, float, double, char, text, date, timestamp, dan lain-lain.
6. Perintah dan Fungsi. MySQL memiliki operator dan fungsi secara penuh yang mendukung
perintah Select dan Where dalam perintah (query).
7. Keamanan. MySQL memiliki beberapa lapisan keamanan seperti level subnetmask, nama
host, dan izin akses user dengan sistem perizinan yang mendetail serta sandi terenkripsi.
8. Skalabilitas dan Pembatasan. MySQL mampu menangani basis data dalam skala besar,
dengan jumlah rekaman (records) lebih dari 50 juta dan 60 ribu tabel serta 5 milyar baris.
Selain itu batas indeks yang dapat ditampung mencapai 32 indeks pada tiap tabelnya.
9. Konektivitas. MySQL dapat melakukan koneksi dengan klien menggunakan protokol
TCP/IP, Unix soket (UNIX), atau Named Pipes (NT).
10.Lokalisasi. MySQL dapat mendeteksi pesan kesalahan pada klien dengan menggunakan lebih
dari dua puluh bahasa. Meski pun demikian, bahasa Indonesia belum termasuk di dalamnya.
11.Antar Muka. MySQL memiliki antar muka (interface) terhadap berbagai aplikasi dan bahasa
pemrograman dengan menggunakan fungsi API (Application Programming Interface).
12.Klien dan Peralatan. MySQL dilengkapi dengan berbagai peralatan (tool)yang dapat
digunakan untuk administrasi basis data, dan pada setiap peralatan yang ada disertakan
petunjuk online.
13.Struktur tabel. MySQL memiliki struktur tabel yang lebih fleksibel dalam menangani
ALTER TABLE, dibandingkan basis data lainnya semacam PostgreSQL ataupun Oracle.
25
2. 4. 3 Bahasa Pemrograman
Terdapat beberapa API (Application Programming Interface) tersedia yang memungkinkan
aplikasi-aplikasi komputer yang ditulis dalam berbagai bahasa pemrograman untuk dapat
mengakses basis data MySQL antara lain: bahasa pemrograman C, C++, C#, bahasa
pemrograman Eiffel, bahasa pemrograman Smalltalk, bahasa pemrograman Java, bahasa
pemrograman Lisp, Perl, PHP, bahasa pemrograman Python, Ruby, REALbasic dan Tcl. Sebuah
antarmuka ODBC memanggil MyODBC yang memungkinkan setiap bahasa pemrograman yang
mendukung ODBC untuk berkomunikasi dengan basis data MySQL. Kebanyakan kode sumber
MySQL dalam ANSI C.
26
BAB 3
ANALISIS DAN PERANCANGAN SISTEM
3. 1 Analisis Sistem yang Sedang Berjalan
Dalam membangun sebuah sistem pakar yang sesuai dengan kebutuhan tentu diperlukan
analisis terhadap sistem umum yang ada atau sistem umum yang sedang berjalan. Tujuan dari
menganalisis sistem yang sedang berjalan yaitu supaya sistem pakar yang dibangun tidak keluar
dari sistem inti yaitu sistem pakar diagnosis penyakit batuk.
Adapun pengguna yang terlibat dalam sistem yang sedang berjalan adalah sebagai berikut :
1. Dokter
2. Pasien
Adapun prosedur yang digunakan saat ini, yaitu :
1. Pasien mendatangi klinik, puskesmas, maupun rumah sakit.
2. Pasien mendaftarkan diri untuk berobat.
3. Pasien konsultasi dengan dokter tentang penyakit yang mungkin diderita.
4. Menuliskan resep obat untuk dikonsumsi oleh pasien.
5. Pasien menebus resep obat.
3. 2 Analisis Kebutuhan Non Fungsional
Analisis kebutuhan non fungsional ini menggambarkan kebutuhan luar sistem yang
diperlukan seperti kebutuhan perangkat keras, kebutuhan perangkat lunak, dan user yang akan
menggunakan sistem. Hal ini di maksudkan agar sistem dapat digunakan dengan baik sesuai
dengan kebutuhan proses bisnis dari sistem.
3. 2. 1 Analisis Kebutuhan Perangkat Keras
Dalam membangun suatu aplikasi dibutuhkan beberapa komponen perangkat keras
(hardware) yang mendukung jalannya proses untuk membangun aplikasi tersebut. Adapun
spesifikasi dari perangkat keras yang mendukung dalam pembangunan aplikasi ini, meliputi :
1. Prosessor : minimal 1,8 GHz
2. Memory : minimal 512 MB
3. Harddisk : 80 GB
4. VGA : 128 MB
27
3. 2. 2 Analisis Kebutuhan Perangkat Lunak
Selain perangkat keras, perangkat lunak (software) pendukung juga dibutuhkan dalam
membangun sebuah aplikasi. Perangkat lunak pendukung yang digunakan untuk membangun
aplikasi ini meliputi :
1. Sistem Operasi Windows
2. Java SDK
3. Netbean 6.8
4. MySQL
3. 2. 3 Analisis Pengguna (user)
Pengguna (user) dari aplikasi ini adalah sebagai berikut :
1. User yang memiliki pengetahuan tentang penyakit batuk
2. User membutuhkan diagnosis awal penyakit batuk yang mungkin diderita.
3. 2. 4 Analisis Kebutuhan Perangkat Pikir
Suatu sistem pakar akan berjalan optimal apabila ditunjang oleh perangkat pikir yang
memiliki kemampuan dalam menjalankan suatu aplikasi sistem pakar. Adapun perangkat pikir
(user) yang dimiliki saat ini yaitu Dokter dan Pasien yang menderita penyakit batuk yang
memiliki rincian sebagai berikut :
Dokter
Umur : 27 tahun
Pendidikan Terakhir : S1 (Kedokteran)
Kemampuan yang dimiliki : Mampu menggunakan perangkat lunak Office Suite dalam
menjalankan tugasnya.
Pasien
Umur : 15 tahun
Pendidikan minimal : SMA
Kemampuan yang dimiliki : Mampu mengoperasikan komputer (dasar).
Untuk menjalankan aplikasi sistem pakar yang dibangun memerlukan dua macam user yang
terlibat yaitu pakar/dokter (administrator), dan pasien yang dalam hal ini pasien yang menderita
penyakit batuk. Detail penjelasan user tersebut bisa dilihat dalam rincian sebagai berikut :
28
Pakar/Dokter (Administrator)
Umur : 27 tahun
Pendidikan terakhir : S1 (Kedokteran)
Kemampuan yang dimiliki : Menguasai ilmu kedokteran umum dan mampu
mengoperasikan komputer serta pernah menggunakan
aplikasi sistem pakar sebelumnya.
Pasien
Umur : 15
Pendidikan terakhir : SMA
Kemampuan yang dimiliki : Mampu mengoperasikan komputer (dasar)
3. 2. 4. 1 Analisis Sistem Pakar
Dalam membangun sistem pakar dilakukan beberapa tahapan analisis :
1. Informasi menemukan masalah yang akan dibangun sistem pakarnya.
2. Mengumpulkan data-data yang diperlukan untuk membangun sistem pakar, berupa jenis
penyakit, pengertian penyakit, gejala penyakit, dan saran pengobatan suatu penyakit melalui
studi literatur yang akan digunakan sebagai base knowledge.
3. Merepresentasikan pengetahuan yang telah didapat ke dalam tabel gejala yang telah
dianalisis , aturan kaidah produksi serta pohon pelacakan dan penulisan gejala da penyakit.
4. Menemukan metode inferensi yang digunakan .
5. Menemukan target user yang akan menggunakan aplikasi sistem pakar ini.
6. Usulan sistem yang telah dibangun.
3. 2. 4. 2 Analisis Masalah
Salah satu masalah yang sedang dihadapi dunia kedokteran yaitu keterbatasan sumber daya
manusia, sementara itu kebutuhan tenaga spesialis terus meningkat, sedang aplikasi yang terbatas
pengetahuan tentang kedokteran yang dipadukan dengan kolom konsultasi masih sangat terbatas.
3. 2. 4. 3 Analisis Kebutuhan Data
Proses ini dilakukan untuk memperoleh data mengenai jenis penyakit batuk beserta
gejalanya dengan membawa data yang belum didapat dari buku referensi untuk diperiksa
kebenarannya ke beberapa sumber agar didapat data yang lebih akurat. Setiap penyakit pasti
memiliki gejala yang bisa kita tentukan jenisnya sehingga antara penyakit satu dengan yang
lainnya pasti terdapat perbedaan, demikian pula pada penyakit batuk walaupun ada yang mirip
tetapi salah satu diantaranya memiliki gejala khusus yang tidak dimiliki jenis penyakit batuk
lainnya. Data mengenai jenis dan gejala-gejala penyakit batuk dari proses literatur adalah sebagai
berikut :
29
Table 3.1 Penyakit dan gejala serta penanganannya
No Nama Penyakit Penyebab Gejala Penanganan
1. Batuk Kering Alergi, kondisi
tubuh menurun.
Tenggorokan kering,
gatal, perih, susah
nelan.
Segera minum obat
(misalnya, Actifed DM
Syrup 120 mL, Lapifed
DM Syrup 100 mL,
atau obat-obat yang
mengandung Anti-tusif
), hindari sesuatu yang
menyebabkan alergi
(misalnya debu, asap
rokok, dan air dingin).
2. Batuk Berdahak Infeksi, virus jika
dahak putih, bakteri
jika dahak kuning
atau hijau.
Sesak napas,
mengeluarkan lendir
(dahak), napas
mengeluarkan bunyi,
bersin-bersin.
Segera minum obat
(misalnya Actifed
Expectorant 60 mL,
Bisolvon tablet 8 mg x
10 x 4, atau obat-obat
yang mengandung
Expectorants)
3. 2. 4. 4 Konseptualisasi
Sistem diagnosis yang akan dibuat adalah sistem diagnosis aturan (Rule Based Reasoning ).
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 penyakit, kaidah produksi,
dan pohon gejala.
1. Tabel gejala :
Tabel gejala mengenal penyakit batuk yang dianalisis dari berbagai sumber dapat dilihat
pada tabel berikut :
30
Table 3.2 Gejala-gejala penyakit batuk
No Gejala A B
1. Sesak napas *
2. Susah nelan *
3. Tenggorokan kering *
4. Tenggorokan gatal *
5. Mengeluarkan lender *
6. Napas mengeluarkan bunyi *
7. Tenggorokan perih *
8. Bersin-bersin *
9. Suara Serak *
2. Tabel Penyakit
Tabel penyakit menunjukkan jenis-jenis penyakit batuk yang ada.
Table 3.3 Jenis penyakit batuk
Kode Nama Penyakit
A Batuk Kering
B Batuk Berdahak
3. Tabel Kaidah Produksi
Tabel kaidah produksi menunjukkan aturan produksi untuk menentukan jenis penyakit batuk
yang diderita.
Table 3.4 Kaidah produksi
1.IF tenggorokan kering AND tenggorokan gatal AND tenggorokan perih
AND susah nelan THEN Batuk Kering
2.IF sesak napas AND mengeluarkan lendir AND napas mengeluarkan
bunyi AND bersin-bersin THEN Batuk Berdahak.
4. Pohon Gejala
Gambar pohon gejala menunjukkan penjabaran gejala-gejala sampai mendapatkan jenis
penyakit yang diderita.
31
Gambar 3.1 Pohon Pelacakan
Keterangan :
Gejala
Penyakit
Tidak Terdiagnosa
Jika jawaban “Ya”
Jika jawaban “Tidak”
3. 3 Analisis Kebutuhan Fungsional
Analisis kebutuhan fungsional menggambarkan proses kegiatan yang akan diterapkan dalam
sistem dan menjelaskan kebutuhan yang diperlukan agar sistem dapat berjalan dengan baik serta
sesuai dengan kebutuhan proses bisnis sistem yang bersangkutan.
Analisis yang dilakukan dimodelkan dengan menggunakan UML (Unified Modeling
Language). Tahapan pemodelan dalam analisis tersebut antara lain mengidentifikasi aktor,
pembuatan use case diagram, use case scenario, activity diagram, sequence diagram, class
diagram, dan state diagram.
3. 3. 1 Identifikasi Aktor
Adapun aktor yang dapat diidentifikasi dalam sistem ini adalah sebagai berikut :
1. Aktor pertama adalah pakar (administrator) sebagai pengatur atau administrator yang
mempunyai hak akses mengelola data tentang penyakit batuk.
2. Aktor kedua adalah pasien yang menderita penyakit batuk yang bisa menjawab pertanyaan
dan melihat hasil diagnosis penyakit batuk yang diderita.
32
3. 3. 2 Use Case Diagram
Use case adalah konstruksi untuk mendeskripsikan bagaimana sistem terlihat dimata
pengguna. Sasaran pemodelan use case diantaranya adalah mendefinisikan kebutuhan fungsional
dan operasional sistem dengan mendefinisikan skenario penggunaan yang disepakati antara
pemakai dan pengembang (developer). Dari identifikasi aktor yang terlibat di atas maka use case
diagram untuk sistem pakar diagnosis penyakit batuk dapat dilihat dalam gambar 3.2 .
33
<<include>>
<<include>>
Gambar 3.2 Use Case diagram semua aktor
34
3. 3. 2. 1 Use Case Diagram dengan Aktor Pakar (Administrator)
Use Case Diagram sistem pakar diagnosis penyakit batuk dengan aktor pakar
(administrator) dapat dilihat pada gambar 3.3 di bawah ini :
<<include>>
<<include>>
Gambar 3.3 Use Case diagram dengan Aktor Pakar (Administrator)
35
3. 3. 2. 2 Use Case Diagram dengan Aktor Pasien
Use Case Diagram sistem pakar diagnosis penyakit batuk dengan aktor pasien dapat dilihat
pada gambar 3-4 di bawah ini :
Gambar 3.4 Use Case diagram dengan Aktor Pasien
3. 3. 3 Use Case Skenario
1. Use Case LoginInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case login
dijelaskan dalam use case skenario sebagai berikut :
Table 3.5 Skenario Use Case Login
IdentifikasiNomor 1Nama LoginTujuan Masuk ke dalam sistem sebagai administratorDeskripsi Proses login administrator merupakan proses
autentikasi untuk menggunakan kewenangan sebagaiadministrator dalam menggunakan sistem.
Aktor Pakar (Administrator)Use case yang berkaitan -
Skenario UtamaKondisi Awal Form login ditampilkan
Aksi Aktor Reaksi Sistem1. Mengisi Form Login 2. Mengautentikasi data login dengan data administrator
pada basis data3. Bila cocok sistem menampilkan halaman menuutama untuk administrator
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan pesan field username dan password harusdi isi2. Menampilkan Form Login
2. Mengisi kembaliFormLogin
3. Mengautentikasi data login dengan data administratorpada basis data
4. Bila cocok sistem menampilkan halaman menuutama untuk administrator
Kondisi Akhir Administrator dapat melakukan kegiatan pada sistemsesuai kewenangan sebagai administrator
36
2. Use Case Manajemen AdministratorInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case
manajemen administrator dijelaskan dalam use case skenario sebagai berikut :
Table 3.6 Skenario Use Case Manajemen Administrator
IdentifikasiNomor 2Nama Manajemen AdmistratorTujuan Mengolah password administratorDeskripsi Proses ini untuk mengolah data password
administrator yang merupakan kepentingan kemananansistem bila adanya perubahan pakar sebagaiadministrator.
Aktor Pakar (Administrator)Use case yang berkaitan Ubah Administrator
Skenario UtamaKondisi Awal Form manajemen administrator ditampilkan
Aksi Aktor Reaksi Sistem1. Memasukan dataAdministrator (username,password, passwordbaru)
2. Mencocokan username dan password lama
3. Bila cocok sistem mengubah data password lama, daripassword lama dengan password yang baru sesuai denganusername
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan pesan bahwa data username atau paswordlamatidak benar
2. Memasukkan dataAdministrator (username,password, passwordbaru, password baru)
3. Mengautentikasi data login dengan data administratorpada basis data
4. Bila cocok sistem mengubah data password lama, daripassword lama dengan password yang baru sesuai denganusername
Kondisi Akhir Administrator dapat mengubah password lama denganpassword yang baru
37
3. Use Case Ubah AdministratorInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case ubah
administrator dijelaskan dalam use case skenario sebagai berikut :
Table 3.7 Skenario Use Case Ubah Administrator
IdentifikasiNomor 3Nama Manajemen Ubah AdministratorTujuan Mengubah data password administratorDeskripsi Proses ini untuk mengubah password administrator
Aktor Pakar (Administrator)Use case yang berkaitan -
Skenario UtamaKondisi Awal Tampilan ubah administrator
Aksi Aktor Reaksi Sistem1. Mengisi formpassword yang akan diubah
2. Melakukan proses ubah password administrator yangdiisi oleh aktor
3. Menyimpan data hasil proses ubah passwordadministrator yang diisi oleh aktor
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formpassword yang akan diubah
3. Melakukan proses ubah password administrator yangdiisi oleh aktor
4. Menyimpan data hasil proses ubah passwordaministrator yang diisi oleh aktor5. Menampilkan pesan password berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data passwordadministrator sesuai dengan kebutuhan
38
4. Use Case Manajemen Data PenyakitInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case
manajemen data penyakit dijelaskan dalam use case skenario sebagai berikut :
Table 3.8 Skenario Use case Manajemen Data Penyakit
IdentifikasiNomor 4Nama Manajemen Data PenyakitTujuan Mengelola data penyakit batuk pada sistemDeskripsi Proses ini untuk mengelola data penyakit batuk
seperti menambah, mengubah, menghapus data penyakitbatuk
Aktor Pakar (Administrator)Use case yang berkaitan Tambah penyakit, Ubah penyakit, hapus penyakit, cari
penyakitSkenario Utama
Kondisi Awal Form manajemen data penyakit ditampilkanAksi Aktor Reaksi Sistem
1. Memilih menu pilihanmanajemen data penyakit(tambah/ubah/hapus)
2. Menampilkan form menu yang dipilih oleh admin(tambah/ubah/hapus)3. Melakukan proses yang dipilih oleh aktor
(tambah/ubah/hapus)4. Menyimpan data hasil proses yang dipilih oleh aktor(tambah/ubah/hapus)5. Menampilkan pesan disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formyang dipilih oleh aktor(tambah/ubah/hapus/cari)
3. Melakukan proses yang dipilih oleh aktor
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data penyakit batukdengan baik dan sesuai kebutuhan
39
5. Use Case Tambah Data PenyakitInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case tambah
data penyakit dijelaskan dalam use case skenario sebagai berikut :
Table 3.9 Skenario Use Case Tambah Data Penyakit
IdentifikasiNomor 5Nama Tambah Data PenyakitTujuan Menambah data penyakit batukDeskripsi Proses penambahan data penyakit batuk
Aktor Pakar (Administrator)Use case yang berkaitan -
Skenario UtamaKondisi Awal Form Tambah Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem1. Mengisi form datatambah data penyakit
2. Melakukan proses penambahan data penyakit
3. Menyimpan data hasil proses penambahan data penyakit
4. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formdata tambah datapenyakit
3. Melakukan proses penambahan data penyakit
4. Menyimpan data hasil proses penambahan data penyakit
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data penyakit sesuaidengan kebutuhan
40
6. Use Case Ubah Data PenyakitInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case ubah
data penyakit dijelaskan dalam use case skenario sebagai berikut :
Table 3.10 Skenario Use Case Ubah Data Penyakit
IdentifikasiNomor 6Nama Ubah Data PenyakitTujuan Mengubah data penyakit batukDeskripsi Proses pengubahan data penyakit batuk
Aktor Pakar (Administrator)Use case yang berkaitan Cari Penyakit
Skenario UtamaKondisi Awal Form Ubah Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem1. memilih data penyakityang akan diubah
2. menampilkan data penyakit yang dipilih
3. Mengisi form datapenyakit yang akandiubah
4. Melakukan proses ubah data penyakit yang diisi olehaktor5. Menyimpan data hasil proses ubah data penyakit yangdiisi oleh aktor6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formubah data penyakit yangakan diubah
3. Melakukan proses ubah data penyakit yang diisi olehaktor
4. Menyimpan data hasil proses ubah data penyakit yangdiisi oleh aktor5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data penyakit sesuaidengan kebutuhan
41
7. Use Case Hapus Data PenyakitInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case hapus
data penyakit dijelaskan dalam use case skenario sebagai berikut :
Table 3.11 Skenario Use Case Hapus Data Penyakit
IdentifikasiNomor 7Nama Hapus Data PenyakitTujuan Menghapus data penyakit batukDeskripsi
Aktor Pakar (Administrator)Use case yang berkaitan Cari Penyakit
Skenario UtamaKondisi Awal Form Hapus Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem1. memilih data penyakityang akan dihapus
2. menampilkan data penyakit yang dipilih
3. Menghapus datapenyakit
4. Menampilkan pesan persetujuan
5. Menghapus datapenyakit
6. Melakukan proses hapus data penyakit
7. Menyimpan data hasil proses hapus data penyakit
8. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Menghapus kembalidata penyakit
3. Menampilkan pesan persetujuan
4. Menghapus kembalidata penyakit
5. Melakukan proses hapus data penyakit
6. Menyimpan data hasil proses hapus data penyakit
7. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menghapus data penyakit sesuaidengan kebutuhan
42
8. Use Case Manajemen Data GejalaInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case
manajemen data gejala dijelaskan dalam use case skenario sebagai berikut :
Table 3.12 Skenario Use Case Lihat Data Manajemen Data Gejala
IdentifikasiNomor 8Nama Manajemen Data GejalaTujuan Mengelola data gejala pada sistemDeskripsi Proses ini untuk mengelola data gejala seperti
menambah, mengubah, menghapus data gejalaAktor Pakar (Administrator)Use case yang berkaitan Tambah gejala, Ubah gejala, hapus gejala, cari gejala
Skenario UtamaKondisi Awal Form manajemen data gejala ditampilkan
Aksi Aktor Reaksi Sistem1. Memilih menu pilihanmanajemen data gejala(tambah/ubah/hapus)
2. Menampilkan form menu yang dipilih oleh admin(tambah/ubah/hapus)3. Melakukan proses yang dipilih oleh aktor
(tambah/ubah/hapus)4. Menyimpan data hasil proses yang dipilih oleh aktor(tambah/ubah/hapus)5. Menampilkan pesan disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formyang dipilih oleh aktor(tambah/ubah/hapus)
3. Melakukan proses yang dipilih oleh aktor
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data gejala denganbaik dan sesuai kebutuhan
43
9. Use Case Tambah GejalaInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case tambah
gejala dijelaskan dalam use case skenario sebagai berikut :
Table 3.13 Skenario Use case Manajemen Diagnosis Tambah Gejala
IdentifikasiNomor 9Nama Tambah GejalaTujuan Menambah data gejala batukDeskripsi Proses penambahan data gejala batuk
Aktor Pakar (Administrator)Use case yang berkaitan -
Skenario UtamaKondisi Awal Form Tambah Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem1. Mengisi form datatambah data gejala
2. Melakukan proses penambahan data gejala
3. Menyimpan data hasil proses penambahan data gejala
4. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formdata tambah data gejala
3. Melakukan proses penambahan data gejala
4. Menyimpan data hasil proses penambahan data gejala
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data gejala sesuaidengan kebutuhan
44
10. Use Case Ubah GejalaInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case ubah
gejala dijelaskan dalam use case skenario sebagai berikut :
Table 3.14 Skenario Use Case Ubah Gejala
IdentifikasiNomor 10Nama Ubah GejalaTujuan Mengubah data gejalaDeskripsi Proses pengubahan data gejala batuk
Aktor Pakar (Administrator)Use case yang berkaitan Cari Gejala
Skenario UtamaKondisi Awal Form Ubah Data Gejala ditampilkan
Aksi Aktor Reaksi Sistem1. memilih data gejalayang akan diubah
2. menampilkan data gejala yang dipilih
3. Mengisi form datagejala yang akan diubah
4. Melakukan proses ubah data gejala yang diisi oleh aktor
5. Menyimpan data hasil proses ubah data gejala yang diisioleh aktor6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formubah data gejala yangakan diubah
3. Melakukan proses ubah data gejala yang diisi oleh aktor
4. Menyimpan data hasil proses ubah data gejala yang diisioleh aktor5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data gejala sesuaidengan kebutuhan
45
11. Use Case Hapus GejalaInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case hapus
gejala dijelaskan dalam use case skenario sebagai berikut :
Table 3.15 Skenario Use Case Hapus Gejala
IdentifikasiNomor 11Nama Hapus GejalaTujuan Menghapus data Gejala batukDeskripsi
Aktor Pakar (Administrator)Use case yang berkaitan Cari Gejala
Skenario UtamaKondisi Awal Form Hapus Data Gejala ditampilkan
Aksi Aktor Reaksi Sistem1. memilih data Gejalayang akan dihapus
2. menampilkan data Gejala yang dipilih
3. Menghapus data Gejala
4. Menampilkan pesan persetujuan
5. Menghapus data Gejala
6. Melakukan proses hapus data Gejala
7. Menyimpan data hasil proses hapus data Gejala
8. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Menghapus kembalidata Gejala
3. Menampilkan pesan persetujuan
4. Menghapus kembalidata Gejala
5. Melakukan proses hapus data Gejala
6. Menyimpan data hasil proses hapus data Gejala
7. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menghapus data Gejala sesuaidengan kebutuhan
12. Use case Manajemen Data Pertanyaan
46
Interaksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case
manajemen data pertanyaan dijelaskan dalam use case skenario sebagai berikut :
Table 3.16 Skenario Use Case Manajemen Data Pertanyaan
IdentifikasiNomor 12Nama Manajemen Data PertanyaanTujuan Mengelola data pertanyaan pada sistemDeskripsi Proses ini untuk mengelola data pertanyaan seperti
menambah, mengubah, menghapus data pertanyaanAktor Pakar (Administrator)Use case yang berkaitan Tambah pertanyaan, Ubah pertanyaan, hapus pertanyaan,
cari pertanyaanSkenario Utama
Kondisi Awal Form manajemen data pertanyaan ditampilkanAksi Aktor Reaksi Sistem
1. Memilih menu pilihanmanajemen datapertanyaan(tambah/ubah/hapus)
2. Menampilkan form menu yang dipilih oleh admin(tambah/ubah/hapus)3. Melakukan proses yang dipilih oleh aktor
(tambah/ubah/hapus)4. Menyimpan data hasil proses yang dipilih oleh aktor(tambah/ubah/hapus)5. Menampilkan pesan disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formyang dipilih oleh aktor(tambah/ubah/hapus)
3. Melakukan proses yang dipilih oleh aktor
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data pertanyaandengan baik dan sesuai kebutuhan
47
13. Use Case Tambah PertanyaanInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case tambah
pertanyaan dijelaskan dalam use case skenario sebagai berikut :
Table 3.17 Skenario Use Case Tambah Pertanyaan
IdentifikasiNomor 13Nama Tambah PertanyaanTujuan Menambah data pertanyaanDeskripsi Proses penambahan data pertanyaan
Aktor Pakar (Administrator)Use case yang berkaitan -
Skenario UtamaKondisi Awal Form Tambah Pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem1. Mengisi form datatambah data pertanyaan
2. Melakukan proses penambahan data pertanyaan
3. Menyimpan data hasil proses penambahan datapertanyaan
4. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formtambah data pertanyaan
3. Melakukan proses penambahan data pertanyaan
4. Menyimpan data hasil proses penambahan datapertanyaan5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data pertanyaansesuai dengan kebutuhan
48
14. Use Case Ubah PertanyaanInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case ubah
pertanyaan dijelaskan dalam use case skenario sebagai berikut :
Table 3.18 Skenario Use Case Ubah Pertanyaan
IdentifikasiNomor 14Nama Ubah PertanyaanTujuan Mengubah data pertanyaanDeskripsi Proses pengubahan data pertanyaan
Aktor Pakar (Administrator)Use case yang berkaitan Cari Pertanyaan
Skenario UtamaKondisi Awal Form Ubah Data Pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem1. memilih datapertanyaan yang akandiubah
2. menampilkan data pertanyaan yang dipilih
3. Mengisi form datapertanyaan yang akandiubah
4. Melakukan proses ubah data pertanyaan yang diisi olehaktor
5. Menyimpan data hasil proses ubah data pertanyaan yangdiisi oleh aktor6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formubah data pertanyaanyang akan diubah
3. Melakukan proses ubah data pertanyaan yang diisi olehaktor
4. Menyimpan data hasil proses ubah data pertanyaan yangdiisi oleh aktor5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data pertanyaansesuai dengan kebutuhan
49
15. Use Case Hapus PertanyaanInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case hapus
pertanyaan dijelaskan dalam use case skenario sebagai berikut :
Table 3.19 Skenario Use Case Hapus Pertanyaan
IdentifikasiNomor 15Nama Hapus PertanyaanTujuan Menghapus data Gejala batukDeskripsi Proses penghapusan data pertanyaan
Aktor Pakar (Administrator)Use case yang berkaitan Cari Pertanyaan
Skenario UtamaKondisi Awal Form Hapus Data Pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem1. memilih datapertanyaan yang akandihapus
2. menampilkan data pertanyaan yang dipilih
3. Menghapus datapertanyaan
4. Menampilkan pesan persetujuan
5. Menghapus datapertanyaan
6. Melakukan proses hapus data pertanyaan
7. Menyimpan data hasil proses hapus data pertanyaan
8. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Menghapus kembalidata pertanyaan
3. Menampilkan pesan persetujuan
4. Menghapus kembalidata pertanyaan
5. Melakukan proses hapus data pertanyaan
6. Menyimpan data hasil proses hapus data pertanyaan
7. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menghapus data pertanyaansesuai dengan kebutuhan
50
16. Use Case Manajemen Data PenangananInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case
manajemen data penanganan dijelaskan dalam use case skenario sebagai berikut :
Table 3.20 Skenario Use Case Manajemen Data Penanganan
IdentifikasiNomor 16Nama Manajemen Data PenangananTujuan Mengelola data penanganan pada sistemDeskripsi Proses ini untuk mengelola data penanganan seperti
menambah, mengubah, menghapus data penangananAktor Pakar (Administrator)Use case yang berkaitan Tambah penanganan, Ubah penanganan, hapus
penanganan, cari penangananSkenario Utama
Kondisi Awal Form manajemen data penanganan ditampilkanAksi Aktor Reaksi Sistem
1. Memilih menu pilihanmanajemen datapenanganan(tambah/ubah/hapus)
2. Menampilkan form menu yang dipilih oleh admin(tambah/ubah/hapus)3. Melakukan proses yang dipilih oleh aktor
(tambah/ubah/hapus)4. Menyimpan data hasil proses yang dipilih oleh aktor(tambah/ubah/hapus)5. Menampilkan pesan disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formyang dipilih oleh aktor(tambah/ubah/hapus)
3. Melakukan proses yang dipilih oleh aktor
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data penanganandengan baik dan sesuai kebutuhan
51
17. Use Case Tambah PenangananInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case tambah
penanganan dijelaskan dalam use case skenario sebagai berikut :
Table 3.21 Skenario Use Case Tambah Penanganan
IdentifikasiNomor 17Nama Tambah PenangananTujuan Menambah data penangananDeskripsi Proses penambahan data penanganan
Aktor Pakar (Administrator)Use case yang berkaitan -
Skenario UtamaKondisi Awal Form Tambah Penanganan ditampilkan
Aksi Aktor Reaksi Sistem1. Mengisi form datatambah data penanganan
2. Melakukan proses penambahan data penanganan
3. Menyimpan data hasil proses penambahan datapenanganan
4. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formtambah data penanganan
3. Melakukan proses penambahan data penanganan
4. Menyimpan data hasil proses penambahan datapenanganan5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data penanganansesuai dengan kebutuhan
52
18. Use Case Ubah PenangananInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case ubah
penanganan dijelaskan dalam use case skenario sebagai berikut :
Table 3.22 Skenario Use Case Ubah Penanganan
IdentifikasiNomor 18Nama Ubah PenangananTujuan Mengubah data penangananDeskripsi Proses pengubahan data penanganan
Aktor Pakar (Administrator)Use case yang berkaitan Cari penanganan
Skenario UtamaKondisi Awal Form Ubah Data Penanganan ditampilkan
Aksi Aktor Reaksi Sistem1. memilih datapenanganan yang akandiubah
2. menampilkan data penanganan yang dipilih
3. Mengisi form datapenanganan yang akandiubah
4. Melakukan proses ubah data penanganan yang diisi olehaktor
5. Menyimpan data hasil proses ubah data penangananyang diisi oleh aktor6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Mengisi kembali formubah data penangananyang akan diubah
3. Melakukan proses ubah data penanganan yang diisi olehaktor
4. Menyimpan data hasil proses ubah data penangananyang diisi oleh aktor5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data penanganansesuai dengan kebutuhan
53
19. Use Case Hapus PenangananInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case hapus
penanganan dijelaskan dalam use case skenario sebagai berikut :
Table 3.23 Skenario Use Case Hapus Penanganan
IdentifikasiNomor 19Nama Hapus PenangananTujuan Menghapus data penangananDeskripsi Proses penghapusan data penanganan
Aktor Pakar (Administrator)Use case yang berkaitan Cari penanganan
Skenario UtamaKondisi Awal Form Hapus Data Penanganan ditampilkan
Aksi Aktor Reaksi Sistem1. memilih datapenanganan yang akandihapus
2. menampilkan data penanganan yang dipilih
3. Menghapus datapenanganan
4. Menampilkan pesan penanganan
5. Menghapus datapenanganan
6. Melakukan proses hapus data penanganan
7. Menyimpan data hasil proses hapus data penanganan
8. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagaldilakukan
2. Menghapus kembalidata penanganan
3. Menampilkan pesan persetujuan
4. Menghapus kembalidata penanganan
5. Melakukan proses hapus data penanganan
6. Menyimpan data hasil proses hapus data penanganan
7. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menghapus data penanganansesuai dengan kebutuhan
54
20. Use Case Manajemen DiagnosisInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case
manajemen diagnosis dijelaskan dalam use case skenario sebagai berikut :
Table 3.24 Skenario Use Case Manajemen Diagnosis
IdentifikasiNomor 4Nama Manajemen DiagnosisTujuan Memperoleh informasi diagnosisDeskripsi Pengguna atau pasien menjawab pertanyaan yang
ditampilkan oleh aplikasi kemudian sistem memprosesjawaban pasien lalu menampilkan hasil diagnosis
Aktor PasienUse case yang berkaitan Lihat, Jawab
Skenario UtamaKondisi Awal Form manajemen diagnosis ditampilkan
Aksi Aktor Reaksi Sistem1. Menjawab pertanyaan 2. Memproses jawaban
3. Menampilkan hasil diagnosis
Skenario Alternatif ( Proses Gagal )Aksi Aktor Reaksi Sistem
Kondisi Akhir
55
21. Use Case JawabInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case jawab
dijelaskan dalam use case skenario sebagai berikut :
22. Use Case LihatInteraksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case lihat
dijelaskan dalam use case skenario sebagai berikut :
56
3. 3. 4 Activity Diagram
Diagram aktifitas (Activity diagram) memodelkan aliran kerja atau workflow sebuah proses
bisnis dan urutan aktifitas dalm suatu proses. Berikut gambaran diagram aktifitas dalam sistem
pakar diagnosis penyakit batuk.
3. 3. 4. 1 Activity Diagram untuk Proses Login
SistemPakar (Administrator)
Menampilkan Form Login
Mengisi Form Login Memeriksa apa masih ada field yang kosong?
Menampilkan pesan masih ada field yang kosong Memeriksa data login
Menampilkan pesan data login salah Menampilkan Menu Administrator
Masih kosongSudah terisi
Data Admin salahData Admin benar
Gambar 3.5 Activity Diagram untuk Proses Login
57
3. 3. 4. 2 Activity Diagram untuk Proses Manajemen Administrator
Gambar 3.6 Activity Diagram untuk Proses Manajemen Administrator
58
3. 3. 4. 3 Activity Diagram untuk Proses Manajemen Data Penyakit
Gambar 3.7 Activity Diagram untuk Proses Manajemen Data Penyakit
59
3. 3. 4. 4 Activity Diagram untuk Proses Manajemen Data Gejala
Gambar 3.8 Activity Diagram untuk Proses Manajemen Data Gejala
60
3. 3. 4. 5 Activity Diagram untuk Proses Manajemen Data Pertanyaan
SistemPakar (Administrator)
Menampilkan Form Manajemen PertanyaanMenentukan kegiatan manajemen yang dilakukan
Menyimpan hasil manajemen yang dilakukan
Mengisi form
Menambah data
Tambah
Menentukan data yang akan diubah
Mengisi form dengan data baru
Mengubah data
Menentukan data yang akan dihapus
Menghapus data
Memproses penambahan data
Memproses pengubahan data
Memproses penghapusan data
Ubah
Hapus
Berhasil
Gagal
Berhasil
Gagal
Gagal
Berhasil
Gambar 3.9 Activity Diagram untuk Proses Manajemen Data Pertanyaan
61
3. 3. 4. 6 Activity Diagram untuk Proses Manajemen Data Penanganan
SistemPakar (Administrator)
Menampilkan Form Manajemen PenangananMenentukan kegiatan manajemen yang dilakukan
Menyimpan hasil manajemen yang dilakukan
Mengisi form
Menambah data
Tambah
Menentukan data yang akan diubah
Mengisi form dengan data baru
Mengubah data
Menentukan data yang akan dihapus
Menghapus data
Memproses penambahan data
Memproses pengubahan data
Memproses penghapusan data
Ubah
Hapus
Berhasil
Gagal
Berhasil
Gagal
Gagal
Berhasil
Gambar 3.10 Activity Diagram untuk Proses Manajemen Data Penanganan
62
3. 3. 4. 7 Activity Diagram untuk Proses Manajemen Diagnosis
Gambar 3.11 Activity Diagram untuk Proses Manajemen Diagnosis
3. 3. 5 Sequence Diagram
Use Case menggambarkan interaksi antar masing-masig objek pada setiap use case dalam
urutan waktu. Interaksi ini berupa pengiriman serangkaian data antar objek-objek yang saling
berinteraksi.
3. 3. 5. 1 Sequence Diagram untuk use case Login
Sequence diagram untuk use case Login menggambarkan interaksi antara objek dari class
pakar (admininistrator) dan objek yang berkaitan dengan proses login lainnya yang menunjukkan
rangkaian pesan yang dikirim antara objek juga interaksi antar objek yang terjadi pada titik
tertentu dalam eksekusi sistem.
63
Pakar (Administrator)Form Login LoginController
Boundary: Control :
MemasukkanDataAdministrator()
PanggilProsesLogin()
PeriksaFiled()
TampilPesanAdaFieldKosong()
tampilPesan()
PakarModelControl :
panggilProsesLogin()
PakarDAOControl :
PakarDAOImplControl :
PakarEntity :
panggilDaoProsesLogin()
panggilDaoImplProsesLogin()
validasiDataPakar()
prosesDataUser()
validasiDataUser()
daoImplProsesLogin(salah/benar)
daoProsesLogin(salah/benar)
prosesLogin(salah)
tampilkanPesanDataSalah()
tampilPesanDataSalah()
prosesLogin(benar)
tampilkanFormPakar()
tampilFormPakar()
Gambar 3.12 Sequence Diagram untuk use case Login
3. 3. 5. 2 Sequence Diagram untuk use case Manajemen Administrator
Sequence diagram untuk use case Manajemen Administrator menggambarkan interaksi
antara objek dari class pakar (admininistrator) dan objek yang berkaitan dengan proses
manajemen administrator yaitu ubah administrator lainnya yang menunjukkan rangkaian pesan
yang dikirim antara objek juga interaksi antar objek yang terjadi pada titik tertentu dalam
eksekusi sistem.
64
Pakar (Administrator)
FormPengaturan PengaturanControllerBoundary: Control :
MemasukkanDataAdministrator()
PanggilUbahPassword()
TampilPesanAdaFieldKosong()
tampilPesan()
PakarModelControl :
PakarDAO PakarDAOImplControl : Control : Pakar
Entity :
periksaField()
PanggilubahPassword()
panggilDaoUbah()
panggilDaoImplUbah()
Ubah(Pakar)
prosesUbah(pakar)
Ubah(Pakar)
prosesSimpan(pakar)daoImplUbah(gagal/sukses)
daoUbah(gagal/sukses)
ubahPakar(gagal)
tampilPesanGagalUbah()
tampilPesan()
ubahPakar(sukses)
tampilPesanSuksesUbah()
tampilPesan()
Gambar 3.13 Sequence Diagram untuk use case Manajemen Administrator
3. 3. 5. 3 Sequence Diagram untuk use case Manajemen Data Penyakit
Sequence diagram untuk use case Manajemen Data Penyakit menggambarkan interaksi
antara objek dari class pakar (admininistrator) dan objek yang berkaitan dengan proses
manajemen data penyakit yaitu proses tambah data, ubah data, hapus data dan cari data lainnya
yang menunjukkan rangkaian pesan yang dikirim antara objek juga interaksi antar objek yang
terjadi pada titik tertentu dalam eksekusi sistem.
65
Gambar 3.14 Sequence Diagram untuk use case Manajemen Data Penyakit
3. 3. 5. 4 Sequence Diagram untuk use case Manajemen Data Gejala
Sequence diagram untuk use case Manajemen Data Gejala menggambarkan interaksi antara
objek dari class pakar (admininistrator) dan objek yang berkaitan dengan proses manajemen data
gejala yaitu proses tambah data, ubah data, hapus data dan cari data lainnya yang menunjukkan
rangkaian pesan yang dikirim antara objek juga interaksi antar objek yang terjadi pada titik
tertentu dalam eksekusi sistem.
66
Pakar (Administrator)FormGejala GejalaController
Boundary: Control :GejalaModel
Control :
pilihKegiatanManajemenDataInformasi()
MasukkanData()
PanggilControlTambah()
PeriksaField()
tampilPesanAdaFieldKosong()
tampilPesan() panggilModelTambah()
GejalaDAOControl :
GejalaDAOImpl GejalaControl :
panggilDaoTambah()
panggilDaoImplTambah()
tambah(gejala)
prosesTambah(gejala)
pilihData()
memasukkanDataBaru()
panggilControllerUbah()
periksaField()
tampilkanPesanAdaFieldKosong()
tampilPesan() panggilModelUbah()
panggilDaoUbah()
panggilDaoImplUbah()
ubah(gejala)
prosesUbah(gejala)
pilihData()
menghapusData()
panggilControllerHapus()
tampilkanPermintaan()
mengisiData()
panggilControlHapus()
periksaData()
tampilkanPesanDataTidakValid()
tampilPesan() panggilModelHapus()
panggilDaoHapus()
panggilDaoImplHapus()
hapus(gejala)
prosesHapus(gejala)
hapus(gejala)
prosesSimpan(gejala)daoImpl(gagal/sukses)
dao(gagal/sukses)
model(gagal)
model(sukses)
tampilkanPesanDataGagal()
tampilPesan()
tampilkanPesanDataSukses()
tampilPesan()
Gambar 3.15 Sequence Diagram untuk use case Manajemen Data Gejala
3. 3. 5. 5 Sequence Diagram untuk use case Manajemen Data Pertanyaan
Sequence diagram untuk use case Manajemen Data Pertanyaan menggambarkan interaksi
antara objek dari class pakar (admininistrator) dan objek yang berkaitan dengan proses
manajemen data pertanyaan yaitu proses tambah data, ubah data, hapus data dan cari data lainnya
67
yang menunjukkan rangkaian pesan yang dikirim antara objek juga interaksi antar objek yang
terjadi pada titik tertentu dalam eksekusi sistem.
Pakar (Administrator)FormPertanyaan PertanyaanController
Boundary: Control :PertanyaanModel
Control :
pilihKegiatanManajemenDataInformasi()
MasukkanData()
PanggilControlTambah()
PeriksaField()
tampilPesanAdaFieldKosong()
tampilPesan() panggilModelTambah()
PertanyaanDAOControl :
PertanyaanDAOImpl PertanyaanControl :
panggilDaoTambah()
panggilDaoImplTambah()
tambah(pertanyaan)
prosesTambah(pertanyaan)
pilihData()
memasukkanDataBaru()
panggilControllerUbah()
periksaField()
tampilkanPesanAdaFieldKosong()
tampilPesan() panggilModelUbah()
panggilDaoUbah()
panggilDaoImplUbah()
ubah(pertanyaan)
prosesUbah(pertanyaan)
pilihData()
menghapusData()
panggilControllerHapus()
tampilkanPermintaan()
mengisiData()
panggilControlHapus()
periksaData()
tampilkanPesanDataTidakValid()
tampilPesan() panggilModelHapus()
panggilDaoHapus()
panggilDaoImplHapus()
hapus(pertanyaan)
prosesHapus(pertanyaan)
hapus(penyakit)
prosesSimpan(pertanyaan)daoImpl(gagal/sukses)
dao(gagal/sukses)
model(gagal)
model(sukses)
tampilkanPesanDataGagal()
tampilPesan()
tampilkanPesanDataSukses()
tampilPesan()
Gambar 3.16 Sequence Diagram untuk use case Manajemen Data Pertanyaan
3. 3. 5. 6 Sequence Diagram untuk use case Manajemen Data Penanganan
Sequence diagram untuk use case Manajemen Data Penanganan menggambarkan interaksi
antara objek dari class pakar (admininistrator) dan objek yang berkaitan dengan proses
68
manajemen data penanganan yaitu proses tambah data, ubah data, hapus data dan cari data
lainnya yang menunjukkan rangkaian pesan yang dikirim antara objek juga interaksi antar objek
yang terjadi pada titik tertentu dalam eksekusi sistem.
Gambar 3.17 Sequence Diagram untuk use case Manajemen Data Penanganan
3. 3. 5. 7 Sequence Diagram untuk use case Manajemen Diagnosis
Sequence diagram untuk use case Manajemen Diagnosis menggambarkan interaksi antara
objek dari class pakar (admininistrator) dan objek yang berkaitan dengan proses manajemen
69
diagnosis yaitu proses jawab dan lihat yang menunjukkan rangkaian pesan yang dikirim antara
objek juga interaksi antar objek yang terjadi pada titik tertentu dalam eksekusi sistem.
PasienFormManajemenDiagnosis DiagnosisController
Boundary: Control :DiagnosisModel
Control :
klikTombolMulai()
menampilkanPertanyaan()
berijawaban()
panggilControlDiagnosis()
panggilModelDiagnosis()
DiagnosisDAO
panggilDaoDiagnosis()
DiagnosisDAOImplControl : Control :
Object1
panggilDaoImplDiagnosis()
diagnosis(penyakit)
prosesDiagnosis(penyakit)
diagnosis(penyakit)
daoImpl(terdiagnosis/tidak)
dao(terdiagnosis/tidak)
model(tidak)
tampilkanFormHasilDiagnosis(tidak)
tampilFormHasilDiagnosis()
model(terdiagnosis)
tampilkanFormHasilDiagnosis(terdiagnosis)
tampilFormHasilDiagnosis()
Gambar 3.18 Sequence Diagram untuk use case Manajemen Diagnosis
3. 3. 6 Class Diagram
Class Diagram menggambarkan struktur dan hubungan antar objek-objek yang ada pada
sistem. Struktur itu meliputi atribut-atribut dan method-method yang ada pada masing-masing
class, sedangkan hubungnnya meliputi pewarisan asosiasi, generalilasi dll.
70
Gambar 3.19 Class Diagram
71
3. 3. 7 State Diagram
3. 3. 7. 1 State Diagram Proses Login
Gambar 3.20 State Diagram Proses Login
3. 3. 7. 2 State Diagram Proses Manajemen Administrator
Gambar 3.21 State Diagram Proses Manajemen Administrator
72
3. 3. 7. 3 State Diagram Proses Manajemen Data Penyakit
Buka form manajemen data penyakittampil form manajemen data penyakit pilih menu
tampil tambah data penyakit tampil ubah penyakit tampil hapus penyakit
memasukan data penyakit baru
form tambah penyakit terisi
klik tombol tambah
periksa fieldada field kosong
tampil pesan field kosong
panggil proses tambah penyakit
tambah penyakit
mengembalikan hasil tambah penyakit
tampil pesan
memasukan kode penyakit
form penyakit
klik tombol cari
periksa fieldada field kosong
tampil pesan fieldkosong
proses pencarian
tampil kode penyakit
klik tombol ubah
tampil ubah penyakit
memasukan data perubahan
form perubahan terisi
klik tombol simpan
simpan penyakit
mengembalikan hasil perubahan
tampil pesan data diubah
memasukan kode penyakit
form penyakit
klik tombol cari
periksa fieldada field kosong
tampil pesan field kosong
proses pencarian
tampil kode penyakit
pilih kode penyakit yg akan dihapus
tampil data yg akan dihapus
klik tombol hapus
hapus data
tampil pesan data dihapus
Gambar 3.22 State Diagram Proses Manajemen Data Penyakit
73
3. 3. 7. 4 State Diagram Proses Manajemen Data Gejala
Buka form manajemen data gejalatampil form manajemen data gejala pilih menu
tampil tambah data gejala tampil ubah gejala tampil hapus gejala
memasukan data gejala baru
form tambah gejala terisi
klik tombol tambah
periksa fieldada field kosong
tampil pesan field kosong
panggil proses tambah gejala
tambah gejala
mengembalikan hasil tambah gejala
tampil pesan
memasukan kode gejala
form gejala
klik tombol cari
periksa fieldada field kosong
tampil pesan fieldkosong
proses pencarian
tampil kode gejala
klik tombol ubah
tampil ubah gejala
memasukan data perubahan
form perubahan terisi
klik tombol simpan
simpan gejala
mengembalikan hasil perubahan
tampil pesan data diubah
memasukan kode gejala
form gejala
klik tombol cari
periksa fieldada field kosong
tampil pesan field kosong
proses pencarian
tampil kode gejala
pilih kode gejala yg akan dihapus
tampil data yg akan dihapus
klik tombol hapus
hapus data
tampil pesan data dihapus
Gambar 3.23 State Diagram Proses Manajemen Data Gejala
74
3. 3. 7. 5 State Diagram Proses Manajemen Data Pertanyaan
Buka form manajemen data pertanyaantampil form manajemen data pertanyaan pilih menu
tampil tambah data pertanyaan tampil ubah pertanyaan tampil hapus pertanyaan
memasukan data pertanyaan baru
form tambah pertanyaan terisi
klik tombol tambah
periksa fieldada field kosong
tampil pesan field kosong
panggil proses tambah pertanyaan
tambah pertanyaan
mengembalikan hasil tambah pertanyaan
tampil pesan
memasukan kode pertanyaan
form pertanyaan
klik tombol cari
periksa fieldada field kosong
tampil pesan fieldkosong
proses pencarian
tampil kode pertanyaan
klik tombol ubah
tampil ubah pertanyaan
memasukan data perubahan
form perubahan terisi
klik tombol simpan
simpan pertanyaan
mengembalikan hasil perubahan
tampil pesan data diubah
memasukan kode pertanyaan
form pertanyaan
klik tombol cari
periksa fieldada field kosong
tampil pesan field kosong
proses pencarian
tampil kode pertanyaan
pilih kode penyakit yg akan dihapus
tampil data yg akan dihapus
klik tombol hapus
hapus data
tampil pesan data dihapus
Gambar 3.24 State Diagram Proses Manajemen Data Pertanyaan
75
3. 3. 7. 6 State Diagram Proses Manajemen Data Penanganan
Gambar 3.25 State Diagram Proses Manajemen Data Penanganan
76
3. 3. 7. 7 State Diagram Proses Manajemen Diagnosis
Gambar 3.26 State Diagram Proses Manajemen Diagnosis
77
3. 4 Perancangan Sistem
Perancangan merupakan penggambaran, perencanaan, dan pembuatan sketsa atau
pengaturan dari beberapa elemen yang terpisah ke dalam suatu kesatuan yang utuh. Tahapan ini
meliputi mengonfigurasi komponen-komponen perangkat lunak dan perangkat keras dari suatu
sistem. Adapun perancangan pakar diagnosis penyakit batuk yang dibuat dijelaskan sebagai
berikut
3. 4. 1 Perancangan Data
Perancangan data merupakan tahapan untuk memetakan model konseptual ke model basis
data yang akan dipakai. Perancangan data terbagi menjadi skema relasi, diagram skema, dan
perancangan struktur tabel. Berikut penjelasan detail perancangan data tersebut :
3. 4. 1. 1 Skema Relasi
Pakar : username, password
Gejala : kodegejala, gejala, kodepenyakit
Penyakit : kodepenyakit, namapenyakit, penyebab
Pertanyaan : kodepertanyaan, pertanyaan, kodegejala
Penanganan : kodepenanganan, penanganan, kodepenyakit, umurpasien
78
3. 4. 1. 2 Diagram Relasi
Gambar 3.27 Diagram Relasi
3. 4. 1. 3 Struktur File
Struktur tabel menggambarkan detail tabel yang berisi field, tipe data, panjang data, dan
keterangan lainnya. Adapun tabel-tabel yang digunakan dalam database sistem informasi travel
ini adalah sebagai berikut:
1. Tabel PakarNama Field Tipe data Size Keterangan
Username Text 10 primarykey
Password Text 10
2. Tabel GejalaNama Field Tipe data Size Keterangan
Kodegejala Text 3 primarykey
79
Gejala Text 20
kodepenyakit Text 2 Foreignkey reference tabel penyakit
3. Tabel PenyakitNama Field Tipe data Size Keterangan
Kodepenyakit Text 2 primarykey
namapenyakit Text 20
penyebab Text 200
4. Tabel PertanyaanNama Field Tipe data Size Keterangan
Kodepertanyaan Text 4 primarykey
pertanyaan Text 150
kodegejala Text 3 Foreignkey reference tabel gejala
5. Tabel PenangananNama Field Tipe data Size Keterangan
Kodepenanganan Text 4 primarykey
penanganan Text 150
kodepenyakit Text 3 Foreignkey reference tabel penyakit
umurpasien Number Integer