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

i
 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

ii
 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

iii
 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

iv
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

v
 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

vi
 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.

1
 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.

Gambar 1.1 Waterfall

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.
 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.
 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.

5
 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
Aktor
1. Menunjukkan user yang akan menggunakan
sistem
2. Usecase
Menunjukkan proses yang terjadi pada sistem
Undirectional Association
3. Menunjukkan hubungan antara aktor dengan
dan 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
Kondisi Awal
1. Menunjukkan awal dari suatu diagram
aktivitas
Kondisi Akhir
2. Menunjukkan akhir dari suatu diagram
aktivitas
3. Kondisi transisi
Menunjukkan kondisi transisi antar aktivitas

Swimlane
4. Menunjukkan aktor dari diagram aktivitas
yang dibuat

Aktivitas
5. Menunjukkan aktivitas-aktivitas yang terdapat
pada diagram aktivitas
Pengecekan kondisi
6. Menunjukkan pengecekan terhadap suatu
kondisi
 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

Objek
1. Menunjukkan objek yang yang terdapat di
diagram sequence

2.
Pesan objek
3. Menunjukkan pesan yang disampaikan ke
objek
lain 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
Table 2.4 Daftar Separator

Separator digunakan untuk menginformasikan ke komplator Java mengenai adanya pengelompokkan di kode progr

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
 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 Tenggorokan kering, Segera minum obat
tubuh menurun. gatal, perih, susah (misalnya, Actifed DM
nelan. 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 Sesak napas, Segera minum obat
dahak putih, bakteri mengeluarkan lendir (misalnya Actifed
jika dahak kuning (dahak), napas Expectorant 60 mL,
atau hijau. mengeluarkan bunyi, Bisolvon tablet 8 mg x
bersin-bersin. 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

IF tenggorokan kering AND tenggorokan gatal AND tenggorokan perih

1.
AND susah nelan THEN Batuk Kering
IF sesak napas AND mengeluarkan lendir AND napas mengeluarkan
2.
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

<<in
c
lude
>>

<<
in
clu
de
>>

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 :

<<in
clud
e>>

<<
inc
lud
e>
>

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 Login
Interaksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case login
dijelaskan dalam use case skenario sebagai berikut :
Table 3.5 Skenario Use Case Login

Identifikasi
Nomor 1
Nama Login
Tujuan Masuk ke dalam sistem sebagai administrator
Deskripsi Proses login administrator merupakan proses
autentikasi untuk menggunakan kewenangan sebagai
administrator dalam menggunakan sistem.
Aktor Pakar (Administrator)
Use case yang berkaitan -
Skenario Utama
Kondisi Awal Form login ditampilkan
Aksi Aktor Reaksi Sistem
1. Mengisi Form Login 2. Mengautentikasi data login dengan data administrator
pada basis data
3. Bila cocok sistem menampilkan halaman menu
utama untuk administrator
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan pesan field username dan password harus
di isi
2. Menampilkan Form Login
2. Mengisi kembali 3. Mengautentikasi data login dengan data administrator
Form pada basis data
Login
4. Bila cocok sistem menampilkan halaman menu
utama untuk administrator
Kondisi Akhir Administrator dapat melakukan kegiatan pada sistem
sesuai kewenangan sebagai administrator
 36

2. Use Case Manajemen Administrator

Interaksi 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

Identifikasi
Nomor 2
Nama Manajemen Admistrator
Tujuan Mengolah password administrator
Deskripsi Proses ini untuk mengolah data password
administrator yang merupakan kepentingan kemananan
sistem bila adanya perubahan pakar sebagai
administrator.
Aktor Pakar (Administrator)
Use case yang berkaitan Ubah Administrator
Skenario Utama
Kondisi Awal Form manajemen administrator ditampilkan
Aksi Aktor Reaksi Sistem
1. Memasukan data 2. Mencocokan username dan password lama
Administrator (username,
password, password
baru)
3. Bila cocok sistem mengubah data password lama, dari
password lama dengan password yang baru sesuai dengan
username
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan pesan bahwa data username atau pasword
lamatidak benar
2. Memasukkan data 3. Mengautentikasi data login dengan data administrator
Administrator (username, pada basis data
password, password
baru, password baru)
4. Bila cocok sistem mengubah data password lama, dari
password lama dengan password yang baru sesuai dengan
username
Kondisi Akhir Administrator dapat mengubah password lama dengan
password yang baru
 37

3. Use Case Ubah Administrator

Interaksi 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

Identifikasi
Nomor 3
Nama Manajemen Ubah Administrator
Tujuan Mengubah data password administrator
Deskripsi Proses ini untuk mengubah password administrator
Aktor Pakar (Administrator)
Use case yang berkaitan -
Skenario Utama
Kondisi Awal Tampilan ubah administrator
Aksi Aktor Reaksi Sistem
1. Mengisi form 2. Melakukan proses ubah password administrator yang
password yang akan di diisi oleh aktor
ubah
3. Menyimpan data hasil proses ubah password
administrator yang diisi oleh aktor
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses ubah password administrator yang
password yang akan di diisi oleh aktor
ubah
4. Menyimpan data hasil proses ubah password
aministrator yang diisi oleh aktor
5. Menampilkan pesan password berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data password
administrator sesuai dengan kebutuhan
 38

4. Use Case Manajemen Data Penyakit

Interaksi 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

Identifikasi
Nomor 4
Nama Manajemen Data Penyakit
Tujuan Mengelola data penyakit batuk pada sistem
Deskripsi Proses ini untuk mengelola data penyakit batuk
seperti menambah, mengubah, menghapus data penyakit
batuk
Aktor Pakar (Administrator)
Use case yang berkaitan Tambah penyakit, Ubah penyakit, hapus penyakit, cari
penyakit
Skenario Utama
Kondisi Awal Form manajemen data penyakit ditampilkan
Aksi Aktor Reaksi Sistem
1. Memilih menu pilihan
manajemen 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 gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses yang dipilih oleh aktor
yang dipilih oleh aktor
(tambah/ubah/hapus/cari)
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data penyakit batuk
dengan baik dan sesuai kebutuhan
 39

5. Use Case Tambah Data Penyakit

Interaksi 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

Identifikasi
Nomor 5
Nama Tambah Data Penyakit
Tujuan Menambah data penyakit batuk
Deskripsi Proses penambahan data penyakit batuk
Aktor Pakar (Administrator)
Use case yang berkaitan -
Skenario Utama
Kondisi Awal Form Tambah Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem
1. Mengisi form data
tambah 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 gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses penambahan data penyakit
data tambah data
penyakit
4. Menyimpan data hasil proses penambahan data penyakit
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data penyakit sesuai
dengan kebutuhan
 40

6. Use Case Ubah Data Penyakit

Interaksi 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

Identifikasi
Nomor 6
Nama Ubah Data Penyakit
Tujuan Mengubah data penyakit batuk
Deskripsi Proses pengubahan data penyakit batuk
Aktor Pakar (Administrator)
Use case yang berkaitan Cari Penyakit
Skenario Utama
Kondisi Awal Form Ubah Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data penyakit
yang akan diubah
2. menampilkan data penyakit yang dipilih
3. Mengisi form data
penyakit yang akan
diubah
4. Melakukan proses ubah data penyakit yang diisi oleh
aktor
5. Menyimpan data hasil proses ubah data penyakit yang
diisi oleh aktor
6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses ubah data penyakit yang diisi oleh
ubah data penyakit yang aktor
akan diubah
4. Menyimpan data hasil proses ubah data penyakit yang
diisi oleh aktor
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data penyakit sesuai
dengan kebutuhan
 41

7. Use Case Hapus Data Penyakit

Interaksi 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

Identifikasi
Nomor 7
Nama Hapus Data Penyakit
Tujuan Menghapus data penyakit batuk
Deskripsi
Aktor Pakar (Administrator)
Use case yang berkaitan Cari Penyakit
Skenario Utama
Kondisi Awal Form Hapus Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data penyakit
yang akan dihapus
2. menampilkan data penyakit yang dipilih
3. Menghapus data
penyakit
4. Menampilkan pesan persetujuan
5. Menghapus data
penyakit
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 gagal
dilakukan
2. Menghapus kembali
data penyakit
3. Menampilkan pesan persetujuan
4. Menghapus kembali
data 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 sesuai
dengan kebutuhan
 42

8. Use Case Manajemen Data Gejala

Interaksi 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

Identifikasi
Nomor 8
Nama Manajemen Data Gejala
Tujuan Mengelola data gejala pada sistem
Deskripsi Proses ini untuk mengelola data gejala seperti
menambah, mengubah, menghapus data gejala
Aktor Pakar (Administrator)
Use case yang berkaitan Tambah gejala, Ubah gejala, hapus gejala, cari gejala
Skenario Utama
Kondisi Awal Form manajemen data gejala ditampilkan
Aksi Aktor Reaksi Sistem
1. Memilih menu pilihan
manajemen 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 gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses yang dipilih oleh aktor
yang dipilih oleh aktor
(tambah/ubah/hapus)
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data gejala dengan
baik dan sesuai kebutuhan
 43

9. Use Case Tambah Gejala

Interaksi 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

Identifikasi
Nomor 9
Nama Tambah Gejala
Tujuan Menambah data gejala batuk
Deskripsi Proses penambahan data gejala batuk
Aktor Pakar (Administrator)
Use case yang berkaitan -
Skenario Utama
Kondisi Awal Form Tambah Data Penyakit ditampilkan
Aksi Aktor Reaksi Sistem
1. Mengisi form data
tambah 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 gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses penambahan data gejala
data tambah data gejala
4. Menyimpan data hasil proses penambahan data gejala
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data gejala sesuai
dengan kebutuhan
 44

10. Use Case Ubah Gejala

Interaksi 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

Identifikasi
Nomor 10
Nama Ubah Gejala
Tujuan Mengubah data gejala
Deskripsi Proses pengubahan data gejala batuk
Aktor Pakar (Administrator)
Use case yang berkaitan Cari Gejala
Skenario Utama
Kondisi Awal Form Ubah Data Gejala ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data gejala
yang akan diubah
2. menampilkan data gejala yang dipilih
3. Mengisi form data
gejala yang akan diubah
4. Melakukan proses ubah data gejala yang diisi oleh aktor
5. Menyimpan data hasil proses ubah data gejala yang diisi
oleh aktor
6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses ubah data gejala yang diisi oleh aktor
ubah data gejala yang
akan diubah
4. Menyimpan data hasil proses ubah data gejala yang diisi
oleh aktor
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data gejala sesuai
dengan kebutuhan
 45

11. Use Case Hapus Gejala

Interaksi 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

Identifikasi
Nomor 11
Nama Hapus Gejala
Tujuan Menghapus data Gejala batuk
Deskripsi
Aktor Pakar (Administrator)
Use case yang berkaitan Cari Gejala
Skenario Utama
Kondisi Awal Form Hapus Data Gejala ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data Gejala
yang 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 gagal
dilakukan
2. Menghapus kembali
data Gejala
3. Menampilkan pesan persetujuan
4. Menghapus kembali
data 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 sesuai
dengan 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

Identifikasi
Nomor 12
Nama Manajemen Data Pertanyaan
Tujuan Mengelola data pertanyaan pada sistem
Deskripsi Proses ini untuk mengelola data pertanyaan seperti
menambah, mengubah, menghapus data pertanyaan
Aktor Pakar (Administrator)
Use case yang berkaitan Tambah pertanyaan, Ubah pertanyaan, hapus pertanyaan,
cari pertanyaan
Skenario Utama
Kondisi Awal Form manajemen data pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem
1. Memilih menu pilihan
manajemen data
pertanyaan
(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 gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses yang dipilih oleh aktor
yang dipilih oleh aktor
(tambah/ubah/hapus)
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data pertanyaan
dengan baik dan sesuai kebutuhan
 47

13. Use Case Tambah Pertanyaan

Interaksi 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

Identifikasi
Nomor 13
Nama Tambah Pertanyaan
Tujuan Menambah data pertanyaan
Deskripsi Proses penambahan data pertanyaan
Aktor Pakar (Administrator)
Use case yang berkaitan -
Skenario Utama
Kondisi Awal Form Tambah Pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem
1. Mengisi form data
tambah data pertanyaan
2. Melakukan proses penambahan data pertanyaan
3. Menyimpan data hasil proses penambahan data
pertanyaan
4. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses penambahan data pertanyaan
tambah data pertanyaan
4. Menyimpan data hasil proses penambahan data
pertanyaan
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data pertanyaan
sesuai dengan kebutuhan
 48

14. Use Case Ubah Pertanyaan

Interaksi 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

Identifikasi
Nomor 14
Nama Ubah Pertanyaan
Tujuan Mengubah data pertanyaan
Deskripsi Proses pengubahan data pertanyaan
Aktor Pakar (Administrator)
Use case yang berkaitan Cari Pertanyaan
Skenario Utama
Kondisi Awal Form Ubah Data Pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data
pertanyaan yang akan
diubah
2. menampilkan data pertanyaan yang dipilih
3. Mengisi form data
pertanyaan yang akan
diubah
4. Melakukan proses ubah data pertanyaan yang diisi oleh
aktor
5. Menyimpan data hasil proses ubah data pertanyaan yang
diisi oleh aktor
6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses ubah data pertanyaan yang diisi oleh
ubah data pertanyaan aktor
yang akan diubah
4. Menyimpan data hasil proses ubah data pertanyaan yang
diisi oleh aktor
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data pertanyaan
sesuai dengan kebutuhan
 49

15. Use Case Hapus Pertanyaan

Interaksi 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

Identifikasi
Nomor 15
Nama Hapus Pertanyaan
Tujuan Menghapus data Gejala batuk
Deskripsi Proses penghapusan data pertanyaan
Aktor Pakar (Administrator)
Use case yang berkaitan Cari Pertanyaan
Skenario Utama
Kondisi Awal Form Hapus Data Pertanyaan ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data
pertanyaan yang akan
dihapus
2. menampilkan data pertanyaan yang dipilih
3. Menghapus data
pertanyaan
4. Menampilkan pesan persetujuan
5. Menghapus data
pertanyaan
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 gagal
dilakukan
2. Menghapus kembali
data pertanyaan
3. Menampilkan pesan persetujuan
4. Menghapus kembali
data 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 pertanyaan
sesuai dengan kebutuhan
 50

16. Use Case Manajemen Data Penanganan

Interaksi 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

Identifikasi
Nomor 16
Nama Manajemen Data Penanganan
Tujuan Mengelola data penanganan pada sistem
Deskripsi Proses ini untuk mengelola data penanganan seperti
menambah, mengubah, menghapus data penanganan
Aktor Pakar (Administrator)
Use case yang berkaitan Tambah penanganan, Ubah penanganan, hapus
penanganan, cari penanganan
Skenario Utama
Kondisi Awal Form manajemen data penanganan ditampilkan
Aksi Aktor Reaksi Sistem
1. Memilih menu pilihan
manajemen data
penanganan
(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 gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses yang dipilih oleh aktor
yang dipilih oleh aktor
(tambah/ubah/hapus)
4. Menyimpan data hasil proses yang dipilih oleh aktor
5. Menampilkan pesan disimpan
Kondisi Akhir Pakar(Administrator) dapat mengelola data penanganan
dengan baik dan sesuai kebutuhan
 51

17. Use Case Tambah Penanganan

Interaksi 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

Identifikasi
Nomor 17
Nama Tambah Penanganan
Tujuan Menambah data penanganan
Deskripsi Proses penambahan data penanganan
Aktor Pakar (Administrator)
Use case yang berkaitan -
Skenario Utama
Kondisi Awal Form Tambah Penanganan ditampilkan
Aksi Aktor Reaksi Sistem
1. Mengisi form data
tambah data penanganan
2. Melakukan proses penambahan data penanganan
3. Menyimpan data hasil proses penambahan data
penanganan
4. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses penambahan data penanganan
tambah data penanganan
4. Menyimpan data hasil proses penambahan data
penanganan
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat menambah data penanganan
sesuai dengan kebutuhan
 52

18. Use Case Ubah Penanganan

Interaksi 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

Identifikasi
Nomor 18
Nama Ubah Penanganan
Tujuan Mengubah data penanganan
Deskripsi Proses pengubahan data penanganan
Aktor Pakar (Administrator)
Use case yang berkaitan Cari penanganan
Skenario Utama
Kondisi Awal Form Ubah Data Penanganan ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data
penanganan yang akan
diubah
2. menampilkan data penanganan yang dipilih
3. Mengisi form data
penanganan yang akan
diubah
4. Melakukan proses ubah data penanganan yang diisi oleh
aktor
5. Menyimpan data hasil proses ubah data penanganan
yang diisi oleh aktor
6. Menampilkan pesan data berhasil disimpan
Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem
1. Menampilkan Pesan bahwa pemrosesan data gagal
dilakukan
2. Mengisi kembali form 3. Melakukan proses ubah data penanganan yang diisi oleh
ubah data penanganan aktor
yang akan diubah
4. Menyimpan data hasil proses ubah data penanganan
yang diisi oleh aktor
5. Menampilkan pesan data berhasil disimpan
Kondisi Akhir Pakar(Administrator) dapat mengubah data penanganan
sesuai dengan kebutuhan
 53

19. Use Case Hapus Penanganan

Interaksi 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

Identifikasi
Nomor 19
Nama Hapus Penanganan
Tujuan Menghapus data penanganan
Deskripsi Proses penghapusan data penanganan
Aktor Pakar (Administrator)
Use case yang berkaitan Cari penanganan
Skenario Utama
Kondisi Awal Form Hapus Data Penanganan ditampilkan
Aksi Aktor Reaksi Sistem
1. memilih data
penanganan yang akan
dihapus
2. menampilkan data penanganan yang dipilih
3. Menghapus data
penanganan
4. Menampilkan pesan penanganan
5. Menghapus data
penanganan
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 gagal
dilakukan
2. Menghapus kembali
data penanganan
3. Menampilkan pesan persetujuan
4. Menghapus kembali
data 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 penanganan
sesuai dengan kebutuhan
 54

20. Use Case Manajemen Diagnosis

Interaksi 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

Identifikasi
Nomor 4
Nama Manajemen Diagnosis
Tujuan Memperoleh informasi diagnosis
Deskripsi Pengguna atau pasien menjawab pertanyaan yang
ditampilkan oleh aplikasi kemudian sistem memproses
jawaban pasien lalu menampilkan hasil diagnosis
Aktor Pasien
Use case yang berkaitan Lihat, Jawab
Skenario Utama
Kondisi Awal Form manajemen diagnosis ditampilkan
Aksi Aktor Reaksi Sistem
1. Menjawab pertanyaan 2. Memproses jawaban

3. Menampilkan hasil diagnosis

Skenario Alternatif ( Proses Gagal )
Aksi Aktor Reaksi Sistem

Kondisi Akhir
 55

21. Use Case Jawab

Interaksi antara aktor pengguna, yaitu Pakar (Administrator) dengan use case jawab
dijelaskan dalam use case skenario sebagai berikut :

22. Use Case Lihat

Interaksi 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

Pakar (Administrator) Sistem

Menampilkan Form Login

Mengisi Form Login Memeriksa apa masih ada field yang kosong?

Masih kosong
Sudah terisi

Menampilkan pesan masih ada field yang kosong Memeriksa data login

Data Admin salah

Data Admin benar

Menampilkan pesan data login salah Menampilkan Menu Administrator

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

Pakar (Administrator) Sistem

Menentukan kegiatan manajemen yang dilakukan Menampilkan Form Manajemen Pertanyaan

Tambah
Mengisi form

Gagal
Ubah

Menambah data Memproses penambahan data

Berhasil

Menentukan data yang akan diubah

Mengisi form dengan data baru

Gagal
Hapus

Mengubah data Memproses pengubahan data

Menentukan data yang akan dihapus Berhasil

Gagal

Menghapus data Memproses penghapusan data

Berhasil

Menyimpan hasil manajemen yang dilakukan

Gambar 3.9 Activity Diagram untuk Proses Manajemen Data Pertanyaan

 61

3. 3. 4. 6 Activity Diagram untuk Proses Manajemen Data Penanganan

Pakar (Administrator) Sistem

Menentukan kegiatan manajemen yang dilakukan Menampilkan Form Manajemen Penanganan

Tambah
Mengisi form

Gagal
Ubah

Menambah data Memproses penambahan data

Berhasil

Menentukan data yang akan diubah

Mengisi form dengan data baru

Gagal
Hapus

Mengubah data Memproses pengubahan data

Menentukan data yang akan dihapus Berhasil

Gagal

Menghapus data Memproses penghapusan data

Berhasil

Menyimpan hasil manajemen yang dilakukan

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

Boundary: Control : Control : Control : Control : Entity :

Form Login LoginController PakarModel PakarDAO PakarDAOImpl Pakar
Pakar (Administrator)

MemasukkanDataAdministrator()

PanggilProsesLogin()

PeriksaFiled()

TampilPesanAdaFieldKosong()

tampilPesan()
panggilProsesLogin()

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

Boundary: Control : Control : Control : Control : Entity :

FormPengaturan PengaturanController PakarModel PakarDAO PakarDAOImpl Pakar

Pakar (Administrator)

MemasukkanDataAdministrator()

PanggilUbahPassword()

periksaField()

TampilPesanAdaFieldKosong()
PanggilubahPassword()
tampilPesan()

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

Boundary: Control : Control : Control : Control :

FormGejala GejalaController GejalaModel GejalaDAO GejalaDAOImpl Gejala
Pakar (Administrator)

pilihKegiatanManajemenDataInformasi()

MasukkanData()

PanggilControlTambah()

PeriksaField()

tampilPesanAdaFieldKosong()

tampilPesan() panggilModelTambah()

panggilDaoTambah()

panggilDaoImplTambah()

pilihData()
tambah(gejala)

memasukkanDataBaru()
prosesTambah(gejala)

panggilControllerUbah()

periksaField()

tampilkanPesanAdaFieldKosong()

tampilPesan() panggilModelUbah()

panggilDaoUbah()

panggilDaoImplUbah()

ubah(gejala)
pilihData()

prosesUbah(gejala)
menghapusData()

panggilControllerHapus()

tampilkanPermintaan()

mengisiData()

panggilControlHapus()

periksaData()

tampilkanPesanDataTidakValid()

panggilModelHapus()
tampilPesan()

panggilDaoHapus()

panggilDaoImplHapus()

hapus(gejala)

prosesHapus(gejala)

hapus(gejala)

daoImpl(gagal/sukses)
prosesSimpan(gejala)
dao(gagal/sukses)

model(gagal)

tampilkanPesanDataGagal()

tampilPesan()

model(sukses)

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.

Boundary: Control : Control : Control : Control :

FormPertanyaan PertanyaanController PertanyaanModel PertanyaanDAO PertanyaanDAOImpl Pertanyaan
Pakar (Administrator)

pilihKegiatanManajemenDataInformasi()

MasukkanData()

PanggilControlTambah()

PeriksaField()

tampilPesanAdaFieldKosong()

tampilPesan() panggilModelTambah()

panggilDaoTambah()

panggilDaoImplTambah()

pilihData()
tambah(pertanyaan)

memasukkanDataBaru()
prosesTambah(pertanyaan)

panggilControllerUbah()

periksaField()

tampilkanPesanAdaFieldKosong()

tampilPesan() panggilModelUbah()

panggilDaoUbah()

panggilDaoImplUbah()

ubah(pertanyaan)
pilihData()

prosesUbah(pertanyaan)
menghapusData()

panggilControllerHapus()

tampilkanPermintaan()

mengisiData()

panggilControlHapus()

periksaData()

tampilkanPesanDataTidakValid()

tampilPesan() panggilModelHapus()

panggilDaoHapus()

panggilDaoImplHapus()

hapus(pertanyaan)

prosesHapus(pertanyaan)

hapus(penyakit)

daoImpl(gagal/sukses)
prosesSimpan(pertanyaan)
dao(gagal/sukses)

model(gagal)

tampilkanPesanDataGagal()

tampilPesan()

model(sukses)

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.

Boundary: Control : Control : Control : Control :

DiagnosisController DiagnosisModel DiagnosisDAO DiagnosisDAOImpl Object1
FormManajemenDiagnosis
Pasien

klikTombolMulai()

menampilkanPertanyaan()

berijawaban()

panggilControlDiagnosis()

panggilModelDiagnosis()

panggilDaoDiagnosis()

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 penyakit
tampil form manajemen data penyakit pilih menu

tampil tambah data penyakit tampil ubah penyakit tampil hapus penyakit

memasukan kode penyakit memasukan kode penyakit

memasukan data penyakit baru

form penyakit form penyakit

form tambah penyakit terisi
klik tombol cari klik tombol cari
klik tombol tambah

ada field kosong ada field kosong

ada field kosong tampil pesan field kosong
periksa field tampil pesan fieldkosong periksa field
periksa field tampil pesan field kosong

proses pencarian proses pencarian

panggil proses tambah penyakit

tampil kode penyakit tampil kode penyakit

klik tombol ubah pilih kode penyakit yg akan dihapus

tambah penyakit tampil ubah penyakit tampil data yg akan dihapus

mengembalikan hasil tambah penyakit memasukan data perubahan klik tombol hapus

form perubahan terisi hapus data

tampil pesan

klik tombol simpan

simpan penyakit tampil pesan data dihapus

mengembalikan hasil perubahan

tampil pesan data diubah

Gambar 3.22 State Diagram Proses Manajemen Data Penyakit

 73

3. 3. 7. 4 State Diagram Proses Manajemen Data Gejala

Buka form manajemen data gejala
tampil form manajemen data gejala pilih menu

tampil tambah data gejala tampil ubah gejala tampil hapus gejala

memasukan kode gejala memasukan kode gejala

memasukan data gejala baru

form gejala form gejala

form tambah gejala terisi
klik tombol cari klik tombol cari
klik tombol tambah

ada field kosong ada field kosong

ada field kosong tampil pesan field kosong
periksa field tampil pesan fieldkosong periksa field
periksa field tampil pesan field kosong

proses pencarian proses pencarian

panggil proses tambah gejala

tampil kode gejala tampil kode gejala

klik tombol ubah pilih kode gejala yg akan dihapus

tambah gejala tampil ubah gejala tampil data yg akan dihapus

mengembalikan hasil tambah gejala memasukan data perubahan klik tombol hapus

form perubahan terisi hapus data

tampil pesan

klik tombol simpan

simpan gejala tampil pesan data dihapus

mengembalikan hasil perubahan

tampil pesan data diubah

Gambar 3.23 State Diagram Proses Manajemen Data Gejala

 74

3. 3. 7. 5 State Diagram Proses Manajemen Data Pertanyaan

Buka form manajemen data pertanyaan
tampil form manajemen data pertanyaan pilih menu

tampil tambah data pertanyaan tampil ubah pertanyaan tampil hapus pertanyaan

memasukan kode pertanyaan memasukan kode pertanyaan

memasukan data pertanyaan baru

form pertanyaan form pertanyaan

form tambah pertanyaan terisi
klik tombol cari klik tombol cari
klik tombol tambah

ada field kosong ada field kosong

ada field kosong tampil pesan field kosong
periksa field tampil pesan fieldkosong periksa field
periksa field tampil pesan field kosong

proses pencarian proses pencarian

panggil proses tambah pertanyaan

tampil kode pertanyaan tampil kode pertanyaan

klik tombol ubah pilih kode penyakit yg akan dihapus

tambah pertanyaan tampil ubah pertanyaan tampil data yg akan dihapus

mengembalikan hasil tambah pertanyaan memasukan data perubahan klik tombol hapus

form perubahan terisi hapus data

tampil pesan

klik tombol simpan

simpan pertanyaan tampil pesan data dihapus

mengembalikan hasil perubahan

tampil pesan data diubah

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 Pakar
Nama Field Tipe data Size Keterangan
Username Text 10 primarykey
Password Text 10

2. Tabel Gejala
Nama Field Tipe data Size Keterangan
Kodegejala Text 3 primarykey
 79

Gejala Text 20
kodepenyakit Text 2 Foreignkey reference tabel penyakit

3. Tabel Penyakit
Nama Field Tipe data Size Keterangan
Kodepenyakit Text 2 primarykey
namapenyakit Text 20
penyebab Text 200

4. Tabel Pertanyaan
Nama Field Tipe data Size Keterangan
Kodepertanyaan Text 4 primarykey
pertanyaan Text 150
kodegejala Text 3 Foreignkey reference tabel gejala

5. Tabel Penanganan
Nama Field Tipe data Size Keterangan
Kodepenanganan Text 4 primarykey
penanganan Text 150
kodepenyakit Text 3 Foreignkey reference tabel penyakit
umurpasien Number Integer