BAB 2 LANDASAN TEORI Bab ini berisi teori – teori pendukung yang digunakan dalam pembuatan aplikasi, diantaranya adalah pengertian kecerdasan buatan, pengertian sistem pakar, metode Fuzzy Logic, dan hal – hal yang terkait. 2.1 Teori Umum 2.1.1 Rekayasa Perangkat Lunak 2.1.1.1 Pengertian Rekayasa Perangkat Lunak Menurut Pressman (2010, p4) perangkat lunak adalah : - Instruksi (program komputer) yang ketika dijalankan menyediakan fitur, fungsi, dan tampilan yang diinginkan. - Struktur data yang memungkinkan program untuk secara memadai memanipulasi informasi. - Informasi deskriptif pada hard copy dan virtual form yang menggambarkan operasi dan program yang digunakan. 10
93
Embed
library.binus.ac.idlibrary.binus.ac.id/eColls/eThesisdoc/Bab2DOC/2011-2... · Web viewBeberapa perangkat lunak sistem seperti compilers, editors, dan file management utilities. Pada
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
BAB 2
LANDASAN TEORI
Bab ini berisi teori – teori pendukung yang digunakan dalam pembuatan aplikasi,
diantaranya adalah pengertian kecerdasan buatan, pengertian sistem pakar, metode
Fuzzy Logic, dan hal – hal yang terkait.
2.1 Teori Umum
2.1.1 Rekayasa Perangkat Lunak
2.1.1.1 Pengertian Rekayasa Perangkat Lunak
Menurut Pressman (2010, p4) perangkat lunak adalah :
- Instruksi (program komputer) yang ketika dijalankan menyediakan fitur,
fungsi, dan tampilan yang diinginkan.
- Struktur data yang memungkinkan program untuk secara memadai
memanipulasi informasi.
- Informasi deskriptif pada hard copy dan virtual form yang menggambarkan
operasi dan program yang digunakan.
Menurut Pressman (2010, p7) ada tujuh kategori software komputer yang
memberikan tantangan terhadap pengembang perangkat lunak :
1. System software yaitu, kumpulan program yang ditulis untuk melayani program
lain. Beberapa perangkat lunak sistem seperti compilers, editors, dan file
management utilities. Pada kasus area perangkat lunak sistem ditandai dengan
interaksi berat dengan perangkat keras komputer, penggunaan berat oleh
beberapa pengguna, operasi bersamaan yang membutuhkan penjadwalan,
10
11
berbagi sumber daya, manajemen proses yang canggih, struktur data yang
kompleks, dan antarmuka eksternal yang ganda.
2. Application software, program yang berdiri sendiri memecahkan bisnis spesifik
yang dibutuhkan. Aplikasi pada area proses bisnis atau teknikal data dengan cara
memfasilitasi operasi bisnis atau manajemen pengambilan keputusan teknis.
Selain aplikasi pengolahan data konvensional, aplikasi perangkat lunak
digunakan untuk mengontrol fungsi bisnis secara real time.
3. Scientific software, ditandai dengan algoritma “number crunching”. Aplikasi
berkisar pada astronomi untuk vulkanologi, dari analisis tegangan automotif
untuk ruang orbit antar jemput yang dinamis.
4. Embedded software, yaitu terletak dalam suatu produk atau sistem dan
digunakan untuk sistem itu sendiri. Dapat memberikan fungsi signifikan,
misalnya fungsi digital dalam sebuah kontrol bahan bakar mobil.
5. Product – line software, dirancang untuk memberikan kemampuan khusus untuk
digunakan oleh banyak pelanggan yang berbeda. Contohnya persediaan kontrol
produk.
6. Web application, terkait dengan hypertext yang menyajikan informasi
menggunakan teks dan grafis yang terbatas. Namun, setelah web 2.0 muncul,
webapps berkembang menjadi lingkungan komputasi canggih yang tidak hanya
menyediakan stand – alone feature, fungsi komputasi, dan konten kepada
pengguna akhir, tetapi juga terintegrasi dengan database perusahaan dan aplikasi
bisnis.
7. Artificial intelligence software, menggunakan algoritma non numerical untuk
memecahkan masalah yang kompleks yang tidak bisa menerima perhitungan
12
atau analisis langsung. Aplikasi dalam wilayah ini meliputi robotika, sistem
pakar, pengenalan pola, jaringan syaraf tiruan, dan game.
Menurut Pressman (2010, p14) rekayasa perangkat lunak adalah sebuah
teknologi yang harus terdiri dari lapisan :
- Fokus pada kualitas
Pendekatan teknik apapun (termasuk rekayasa perangkat lunak) harus
bersandar pada komitmen organisasi terhadap suatu mutu. Total kualitas
manajemen dan filosofi yang sama mendorong budaya perbaikan proses yang
berkesinambungan, dan budaya inilah yang mengarah pada pengembangan
pendekatan yang semakin dewasa untuk rekayasa perangkat lunak.
- Proses
Dasar untuk rekayasa perangkat lunak adalah lapisan proses. Proses pada
rekayasa perangkat lunak adalah perangkat yang mengendalikan teknologi lapisan
(layer) bersama - sama dan memungkinkan pengembangan perangkat lunak yang
rasional dan tepat waktu. Proses mendefinisikan suatu kerangka kerja untuk suatu
set key process areas (KPAs) yang harus ditetapkan untuk penyampaian (delivery)
yang efektif dari teknologi perangkat lunak. Key process areas membentuk dasar
bagi kontrol manajemen proyek perangkat lunak dan menetapkan konteks metode -
metode teknis mana yang diterapkan, produk kerja (model, dokumen, data laporan,
form, dll) yang diproduksi, milestone yang diterapkan, kualitas terjamin dan
perubahan yang dikelola dengan baik.
- Metode
13
Metode rekayasa perangkat lunak menyediakan teknis bagaimana untuk
membangun sebuah perangkat lunak. Metode mencakup tugas dan mencakup
analisis kebutuhan, desain, program konstruksi, pengujian, pemeliharaan.
- Alat bantu
Alat bantu automatis atau semi – automatis menyediakan dukungan untuk
proses dan metode. Ketika alat – alat diintegrasikan, sehingga informasi yang
dibuat oleh satu alat dapat digunakan oleh alat lainnya, sebuah sistem yang
mendukung perangkat lunak, yang disebut computer – aided software engineering
(CASE), didirikan. CASE menggabungkan sebuah software, hardware, dan
database (sebuah repository berisi informasi penting tentang analisis, desain,
program konstruksi dan pengujian) untuk menciptakan lingkungan rekayasa
perangkat lunak yang analog dengan CASE untuk hardware.
Gambar 2.1 Lapisan rekayasa perangkat lunak (Pressman, 2010)
2.1.1.2 Model Proses Waterfall
Menurut Pressman (2010, p39) waterfall model disebut juga dengan model
classic life cycle. Model proses tersebut mengusulkan sebuah pendekatan kepada
14
perkembangan perangkat lunak yang sistematik dan sekuensial, yang mulai dari tingkat
dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan.
Model sekuensi linier melingkupi aktivitas – aktivitas sebagai berikut :
- Komunikasi
Proses pencarian kebutuhan yang diintensifkan dan difokuskan pada
perangkat lunak. Untuk mengetahui sifat dari program yang akan dibuat maka
pengembang perangkat lunak harus mengerti tentang domain informasi dari
perangkat lunak, contohnya fungsi yang dibutuhkan, user interface, dan lain
sebagainya. Komunikasi dititikberatkan untuk mencapai kesepakatan user
requirement dan system requirement.
- Perencanaan
Menetapkan suatu rencana pengembangan dari perangkat lunak antara lain
tugas – tugas teknik yang harus dipenuhi, resiko yang kemungkinan akan dihadapi,
sumber daya yang dibutuhkan, hasil kerja, dan jadwal kerja.
- Pemodelan
Menghasilkan suatu model yang memungkinkan pengembang dan
pelanggan memahami lebih lanjut mengenai kebutuhan software dan perancangan –
perancangan untuk memenuhi kebutuhan tersebut. Desain perangkat lunak
sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah
program yang berbeda; struktur data, arsitektur perangkat lunak, representasi
antarmuka, dan detail (algoritma) procedural. Proses desain menerjemahkan syarat
atau kebutuhan ke dalam sebuah representasi perangkat lunak, yang dapat
diperkirakan demi kualitas sebelum dimulai kegiatan mengkode. Sebagaimana
15
persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi
perangkat lunak.
- Konstruksi
Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca, atau
disebut juga langkah pembuatan kode. Jika desain dilakukan dengan cara yang
lengkap, pembuatan kode dapat diselesaikan secara mekanis.
- Penyebaran
Perangkat lunak dikirim kepada pelanggan yang dimaksudkan untuk
mengevaluasi hasil kerja dan memberikan feedback (umpan balik) berdasarkan
evaluasi tersebut.
Gambar 2.2 Waterfall Model (Pressman, 2010)
2.1.1.3 Delapan Aturan Emas
Ben Sneiderman mengemukakan delapan aturan yang dapat digunakan sebagai
petunjuk dasar perancangan antarmuka bagi pengguna dalam membangun suatu aplikasi
(Smith, 2010, p86). Delapan aturan ini disebut Eight Golden Rules of Interface Design,
yaitu :
1. Berusaha untuk konsisten.
Konsistensi bisa berarti banyak hal. Ada konsistensi tindakan, tata letak layar,
navigasi, dan terminologi. Menyediakan konsistensi dapat membantu pengguna
16
untuk mengetahui apa yang diharapkan dan dapat mempelajari antarmuka
dengan lebih cepat.
2. Memenuhi kegunaan yang universal.
Pengguna yang beragam, membuat desain harus diperhitungkan dalam
pertimbangan – pertimbangan yang kompleks, seperti rentang usia, disabilitas,
dan keragaman teknologi. Mungkin butuh penjelasan bagi pemula, tetapi
shortcuts harus disediakan untuk expert user.
3. Memberikan umpan balik yang informatif.
Untuk setiap aksi, harus ada semacam respon, yang disebut juga umpan balik.
Tindakan yang sering dilakukan dan tidak terlalu penting, dapat diberikan umpan
balik sederhana. Tetapi ketika tindakan merupakan suatu hal yang penting, maka
umpan balik sebaiknya lebih substansial. Contoh : timbulnya respon suara ketika
salah menekan tombol pada waktu input data.
4. Merancang dialog untuk menghasilkan suatu penutupan.
Urutan informasi harus dikelompokkan mulai dari awal, tengah, dan akhir.
Umpan balik yang informatif akan memberikan indikasi bahwa cara yang
dilakukan sudah benar dan dapat mempersiapkan kelompok aksi yang
berikutnya.
5. Memberikan penanganan kesalahan yang sederhana.
Sistem harus dirancang agar pengguna tidak melakukan kesalahan yang serius.
Apabila kesalahan terjadi, sistem dapat mendeteksi kesalahan dengan cepat dan
memberikan mekanisme yang sederhana, sehingga mudah dipahami untuk
penanganan kesalahan.
6. Mudah kembali ke tindakan sebelumnya.
17
Hal tersebut dapat mengurangi kekhawatiran pengguna, karena pengguna
mengetahui bahwa kesalahan yang dilakukan dapat dibatalkan, sehingga
pengguna tidak takut untuk melakukan eksplorasi pilihan – pilihan lain yang
belum biasa digunakan.
7. Mendukung tempat pengendali internal.
Pengguna yang memiliki keterampilan merasa menginginkan untuk mengontrol
sistem dan sistem akan merespon aksi yang mereka lakukan, sehingga tidak
terjadi hal yang sebaliknya bahwa pengguna merasa dikendalikan oleh sistem.
Sebaiknya sistem dirancang sedemikian rupa, sehingga pengguna menjadi
inisiator daripada responden.
8. Mengurangi beban ingatan jangka pendek.
Manusia hanya bisa memproses informasi secara terbatas pada memori jangka
pendeknya, oleh karena itu dibutuhkan tampilan sederhana yang bertujuan untuk
memudahkan, membagi materi menjadi segmen kecil yang dapat lebih mudah
dicerna.
2.1.1.4 The Unified Modelling Language (UML)
Menurut Sommerville (2011, p119) pemodelan sistem adalah proses
mengembangkan abstract models dari suatu sistem, dengan masing – masing
merepresentasikan perspektif yang berbeda dari sistem tersebut. Pemodelan sistem
umumnya merepresentasikan sistem menggunakan beberapa jenis notasi grafis, yang
sekarang hampir selalu didasarkan pada notasi dalam Unified Modelling Language
(UML).
18
Menurut Sommerville (2011, p120) UML telah menjadi bahasa pemodelan
standar untuk pemodelan berorientasi objek. UML memiliki tipe – tipe diagram dan juga
mendukung penciptaan berbagai jenis model sistem.
Dengan menggunakan UML kita dapat membuat model untuk semua jenis
aplikasi perangkat lunak, dimana aplikasi tersebut dapat berjalan pada perangkat keras,
sistem operasi dan jaringan apapun, serta ditulis dalam bahasa apapun. Tetapi karena
UML ditulis menggunakan class dan operation dalam konsep dasarnya, maka lebih
cocok untuk digunakan dalam aplikasi perangkat lunak dalam bahasa – bahasa
berorientasi objek seperti C++, Java, C#, maupun VB.NET.
Konsep dasar UML dapat kita rangkum seperti tabel di bawah ini:
Tabel 2.1 Konsepsi dasar UML (Sommerville, 2011)
Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic
behavior, model management, bisa kita pahami dengan mudah apabila kita mengamati
19
gambar di atas, dari diagrams main concepts bisa dipandang dari term yang akan
muncul pada saat membuat diagram, dan view adalah kategori dari diagram tersebut.
Untuk menguasai UML sebenarnya cukup dua hal yang harus diperhatikan, yaitu :
1. Menguasai pembuatan diagram UML.
2. Menguasai langkah – langkah dalam analisa dan pengembangan dengan UML.
Langkah – langkah penggunaan UML :
1. Buatlah daftar proses bisnis dari level tertinggi untuk mendefinisikan aktivitas dan
proses yang mungkin muncul.
2. Petakan use case untuk setiap proses bisnis untuk mendefinisikan dengan tepat
fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case
diagram dilengkapi dengan constraint, requirement, dan catatan lainnya.
3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik
sistem.
4. Definisikan requirement lain (non fungsional, security, dan sebagainya) yang juga
harus disediakan oleh sistem.
5. Berdasarkan use case diagram mulailah membuat activity diagram.
6. Definisikan objek level atas (package atau domain) dan buatlah sequence atau
collaboration diagram untuk setiap alir pekerjaan. Jika sebuah use case memiliki
sebuah kemungkinan alir normal atau error, buatlah satu diagram untuk masing –
masing alir.
7. Buatlah rancangan user interface model yang menyediakan antarmuka bagi
pengguna untuk menjalankan skenario use case.
8. Berdasarkan model yang sudah ada, buatlah class diagram. Setiap package atau
domain dipecah menjadi hirarki class lengkap dengan atribut dan metodenya. Tetapi
20
akan lebih baik jika setiap class dibuat unit rest untuk menguji fungsionalitas class
dan interaksi dengan class lain.
9. Setelah class diagram dibuat, kemudian dapat dilihat kemungkinan pengelompokan
class menjadi komponen – komponen. Oleh karena itu buatlah komponen diagram
pada tahap ini, dan juga definisikan tes integrasi unik setiap komponen meyakinkan
ia berinteraksi dengan baik.
10. Perhalus deployement program yang telah dibuat. Perinci kemampuan requirement
perangkat lunak sistem operasi, jaringan, dan sebagainya. Petakan komponen ke
dalam node.
11. Mulailah membangun sistem, ada dua pendakatan yang digunakan :
Pendekatan use case, dengan menetapkan use case kepada tim pengembang,
untuk mengembangkan unit kode yang lengkap dengan tes.
Pendekatan komponen, yaitu menetapkan tiap komponen kepada tim
pengembang tertentu.
12. Lakukan uji modul serta uji integrasi serta perbaikan model berserta kodenya. Model
harus sesuai dengan kode yang aktual.
13. Aplikasi siap dirilis.
Menurut survei yang dilakukan pada tahun 2007 oleh Erickson dan Siau
(Sommerville, 2011, p120), menunjukkan sebagian besar pengguna UML berpikir
bahwa lima tipe diagram merepresentasikan esensi bagi suatu sistem :
- Diagram activity
21
Menurut Sommerville (2011, p120) activity diagram menunjukkan aktivitas
yang terlibat di dalam proses atau dalam pengolahan data. Diagram activity seperti
diagram state, merupakan diagram yang digunakan untuk memahami alur kerja dari
objek atau komponen yang dilakukan. Diagram activity dapat digunakan untuk
mevisualisasikan interelasi dan interaksi antara use case yang berbeda, serta sering
digunakan untuk mengasosiasikan dengan class yang berbeda. Kekuatan diagram
activity adalah merepresentasikan concurrent activity.
- Diagram activity
Menurut Sommerville (2011, p120) activity diagram menunjukkan aktivitas
yang terlibat di dalam proses atau dalam pengolahan data. Diagram activity seperti
diagram state, merupakan diagram yang digunakan untuk memahami alur kerja dari
objek atau komponen yang dilakukan. Diagram activity dapat digunakan untuk
mevisualisasikan interelasi dan interaksi antara use case yang berbeda, serta sering
digunakan untuk mengasosiasikan dengan class yang berbeda. Kekuatan diagram
activity adalah merepresentasikan concurrent activity.
Gambar 2.3 Contoh activity diagram (IBM, 2003)
Tell Customer to Order a nonalcoholic Drink
Customer Orders Drink
Make sure customer is at least 21 years old
Get Drink For Customer
Drink is alcoholic
Customer age >=21
Customer’s age <21
22
- Use case
Pemodelan use case pada awalnya dikembangkan oleh Jacobson pada 1990-
an dan dimasukkan dalam rilis pertama UML. Use case secara luas digunakan untuk
mendukung persyaratan dari elicitation. Use case dapat diambil sebagai skenario
sederhana yang menggambarkan apa yang pengguna harapkan dari suatu sistem.
Setiap use case merepresentasikan tugas terpisah yang melibatkan interaksi
eksternal dengan sistem. Use case mengidentifikasi interaksi individu antara sistem
dan pengguna atau sistem lain. Setiap use case harus didokumentasikan dengan
deksripsi tekstual, yang kemudian dapat dikaitkan dengan model lain dalam UML
yang akan membangun skenario dengan lebih terperinci. (Sommerville, 2011, p107).
Gambar 2.4 Use case informal (Sommerville, 2011)
Ada dua aktor dalam gambar 2.4 di atas, operator yang mentransfer data dan
sistem record pasien. Stick figure semula dikembangkan untuk mencakup interaksi
manusia, tetapi sekarang digunakan untuk merepresentasikan sistem ekternal lainnya
dan perangkat keras. Secara formal, use case diagram harus menggunakan lines
tanpa panah, dalam UML panah menunjukkan arah aliran pesan. Dalam use case
pesan melewati dua arah. Namun, tanda panah pada gambar 2.4 digunakan secara
informal untuk menunjukkan bahwa receptionist medis memulai transaksi dan data
ditransfer ke sistem record pasien.
23
Gambar 2.5 Contoh use case (Sommerville, 2011)
Use case terdiri dari :
Aktor : pemakai sistem atau sesuatu yang berinteraksi dengan sistem
merepresentasikan pesan, bukan pemakai individual.
Use case : cara spesifik penggunaan sistem oleh aktor.
Tujuan utama memodelkan use case :
Memutuskan dan mendeskripsikan kebutuhan fungsional sistem.
Memberikan deskripsi yang jelas dan konsisten dari apa yang harus dilakukan.
Melakukan basis yang menyediakan pengujian sistem yang meverifikasi sistem.
Menyediakan kemampuan melacak fungsi analistis menjadi class – class,
operasi – operasi, dan aktual sistem.
Ciri – ciri use case :
Terdapat pola perilaku yang harus dipenuhi oleh sistem.
Terdapat sekuen traksaksi terhubung yang dilakukan oleh aktor dan sistem.
Memberikan informasi yang berharga bagi user.
24
Kegunaan use case :
Menangkap kebutuhan sistem.
Berkomunikasi dengan pemakai akhir dan pakar domain masalah.
Pengkajian sistem.
- Sequence Diagram
Sequence diagram dalam UML terutama digunakan untuk memodelkan
interaksi antara aktor dan objek dalam sistem dan interaksi antara objek itu sendiri.
UML memiliki sintaks yang sangat beragam untuk sequence diagram, yang
memungkinkan perbedaan tipe interaksi yang akan dimodelkan. (Sommerville,
2011, p126).
Sesuai namanya, sequence diagram menunjukkan urutan interaksi yang
terjadi selama use case instance. Diagram sequence dapat digunakan untuk
menggambarkan skenario atau rangkaian langkah – langkah yang telah dilakukan
sebagai response dari sebuah event untuk menghasilkan output tertentu. Sequence
diagram menunjukkan interaksi antara aktor dan sistem dan juga antara komponen
sistem (Sommerville, 2011, p120).
Objek dan aktor yang terlibat, tercantum di bagian atas diagram dengan garis
titik – titik yang ditarik secara vertikal. Interaksi antar objek ditunjukkan dengan
panah yang terhubung. Persegi panjang pada garis putus – putus menunjukkan jalur
lifeline dari objek yang bersangkutan. Anda membaca sequence interaksi dari atas ke
25
bawah. Penjelasan pada tanda panah menunjukkan panggilan ke objek, parameter
mereka, dan return value.
Gambar 2.6 Contoh sequence diagram (Sommerville, 2011)
Dari gambar 2.6 di atas, dapat dijelaskan bahwa :
1. Resepsionis medis memicu metode ViewInfo dalam instance P dari kelas objek
PatientInfo, penyediaan identifier pasien, PID. P adalah objek antarmuka
pengguna, yang ditampilkan sebagai bentuk informasi pasien.
2. Instance P memanggil database untuk mengembalikkan informasi yang