BAB II LANDASAN TEORI
2.1
Rekayasa Perangkat Lunak Roger S. Pressman, Ph.D mengatakan metode rekayasa perangkat lunak
memberikan teknik untuk membangun perangkat lunak. Metode-metode itu menyangkut serangkaian tugas yang luas menyangkut analisis kebutuhan, konstruksi program, desain, pengujian, dan pemeliharaan. Rekayasa perangkat lunak mengandalkan pada serangkaian prinsip dasar yang mengatur setiap area teknologi dan menyangkut aktivitas pemodelan serta teknik-teknik deskriptif (Pressman, Roger S, 2005).
2.1.1
Proses dan Model Rekayasa Perangkat Lunak Proses perangkat lunak merupakan sekumpulan aktifitas yang memiliki
tujuan untuk pengembangan ataupun evolusi perangkat lunak. Aktifitas yang umum dalam semua proses perangkat lunak adalah : a. Spesifikasi: apa
yang
harus dilakukan
oleh
perangkat
lunak
dan
batasan/kendala dalam pengembangannya. b. Pengembangan: proses memproduksi sistem perangkat lunak. c. Validasi: pengujian perangkat lunak berdasarkan perubahan keinginan. d. Evolusi: perubahan perangkat lunak berdasarkan perubahan keinginan. Model proses perangkat lunak merupakan suatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dari perspektif khusus.
Contoh perspektif proses perangkat lunak : a. Perspektif Alur-Kerja (Workflow) – barisan kegiatan. b. Perspektif Alur-Data (Data Flow) – alur informasi. c. Perspektif Peran/Aksi – siapa melakukan apa. Model yang umum dalam pengembangan perangkat lunak adalah :
5
6
a. Air Terjun (Waterfall): Memisahkan dan membedakan antara spesifik dan pengembangan. b. Pengembangan secara evolusi: Spesifikasi dan pengembangan saling bergantian. c. Transformasi formal: Menggunakan suatu model sistem matematika yang ditransformasikan ke implementasi. d. Model Spiral: Proses direpresentasikan sebagai model spiral (bukan berupa barisan aktifitas yang dapat ditrack mundur), setiap loop dalam model spiral menyatakan fase proses. e. Model Prototyping: Sistem dibangun dari sistem yang sudah ada.
2.1.2
Model Prototyping Kadang-kadang klien hanya memberikan beberapa kebutuhan umum
software tanpa detil masukan, proses atau detil keluaran. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form tatap muka pengguna (user interface). Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan perangkat lunak.
Proses pada model prototyping yang bisa di jelaskan sebagai berikut: a. Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan. b. Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek perangkat lunak yang diketahui, dan rancangan ini menjadi dasar pembuatan prototipe. c. Evaluasi prototipe: klien mengevaluasi prototipe yang dibuat dan digunakan untuk memperjelas kebutuhan perangkat lunak (Pressman, Roger S, 2005).. Untuk lebih jelas lagi dapat dilihat pada Gambar 2.1.
7
Gambar 2.1 Model Prototyping Software Engineering : 2000
Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototipe-prototipe dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototipe yang dibuat dapat dimanfaatkan kembali untuk membangun perangkat lunak lebih cepat, namun tidak semua prototipe bisa dimanfaatkan. Sekalipun prototipe memudahkan komunikasi antar pengembang dan klien, membuat klien mendapat gambaran awal dari prototipe, membantu mendapatkan kebutuhan detil lebih baik namun demikian prototipe juga menimbulkan masalah. Masalah-masalah yang ada pada model prototipe: a. Dalam membuat prototipe banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototipe yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. b. Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototipe dalam waktu singkat. Mungkin sistem operasi yang tidak
8
sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.
Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan pengembang
bahwa
prototipe
yang
dibangun
merupakan
alat
untuk
mendefinisikan kebutuhan perangkat lunak (Pressman, Roger S, 2005:83-85).
2.1.3
Metode Pengujian Perangkat Lunak Pengujian adalah sebuah proses terhadap program/aplikasi untuk
menemukan kesalahan dan segala kemungkinan yang akan menimbulkan kesalahan sesuai dengan spesifikasi perangkat lunak yang telah ditentukan sebelum aplikasi tersebut diserahkan kepada pelanggan.
Metode pengujian perangkat lunak terdiri dari: 1. Pengujian Kotak Hitam (Black-Box) Pengujian black-box adalah pengujian yang dilakukan untuk antarmuka perangkat lunak, pengujian ini dilakukan untuk memperlihatkan bahwa fungsifungsi bekerja dengan baik dalam arti masukkan yang diterima dengan benar dan keluaran yang dihasilkan benar-benar tepat, pengintegrasian dari eksternal data berjalan dengan baik (file/table). Pengujian kotak hitam berusaha menemukan kesalahan dalam kategori sebagai berikut (R. Pressman, 2002:551) : a. Fungsi-fungsi yang tidak benar atau hilang. b. Kesalahan antarmuka (interface). c. Kesalahan dalam struktur data atau akses basis data eksternal. d. Kesalahan kinerja. e. Inisialisasi dan kesalahan terminasi.
2.
Pengujian Kotak Putih (White-Box) Pengujian white-box adalah pengujian yang dilakukan lebih dekat lagi untuk
menguji prosedur-prosedur yang ada. Lintasan lojik yang dilalui oleh setiap bagian prosedur diuji dengan memberikan kondisi spesifik.
9
Dengan menggunakan metode pengujian white-box, perekayasa sistem dapat melakukan pilihan pengujian yang : Menjamin pengujian terhadap semua lintasan yang tidak bergantungan minimal satu kali. Mencoba semua keputusan lojik dari sisi ”true” dan ”false”. Eksekusi
semua
pengulangan
dalam
batasan
kondisi
dan
batasan
operasionalnya. Pengujian validasi struktur data internal.
2.2
Model Sekuensial Linear Model sekuensial linear untuk rekayasa perangkat lunak, atau sering disebut
juga dengan “siklus kehidupan klasik” atau “model air terjun”. Model sekuensial linear sebuah pendekatan perkembangan perangkat lunak yang sistematik mulai pada tingkat dan kemajuan sistem pada seluruh analis, desain pengujian dan pemeliharaan, model sekuensial linear melengkapi aktivitas – aktivitas sebagai berikut menurut (Roger S, Pressman, 2002:37-38) : 1. Rekayasa dan pemodelan sistem / informasi Pada tahapan ini dilakukan proses pengumpulan kebutuhan pengguna pada tingkatan sistem dengan sejumlah kecil analisa serta desain tingkat puncak.
2. Analisa kebutuhan perangkat lunak Proses pengumpulan kebutuhan diintensifkan dan difokuskan khususnya pada perangkat lunak. Untuk memahami perangkat lunak yang dibangun, perekayasa perangkat lunak harus memahami daerah (domain) informasi, tingkah laku, unjuk kerja, dan antar muka yang diperlukan.
3. Desain Proses multi langkah yang berfokus pada empat atribut program yang berbeda, struktur data, arsitek perangkat lunak, representasi antar muka, dan detail prosedural. Proses desain menerjemahkan kebutuhan ke dalam sebuah
10
representasi perangkat lunak yang dapat diperkirakan demi kualitas sebelum dimulai
pemunculan
kode.
Sebagaimana
persyaratan,
desain
di
dokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak.
4. Generasi kode Desain harus diterjemahkan ke dalam bentuk mesin yang harus dibaca. Artinya dilakukan pengkodean (coding) berdasarkan desain yang dibuat.
5. Pengujian Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional yaitu mengarahkan oengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa masukan yang dibatasi akan memberikan hasil actual yang sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan Perangkat lunak akan mengalami perubahan setelah disampaikan pada pelanggan. Perubahan akan terjadi karena kesalahan – kesalahan yang telah ditentukan, karena perangkat lunak disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya. Pemeliharaan perangkat lunak mengaplikasikan lagi setiap tahap program sebelumnya dan tidak membuat. Untuk lebih jelasnya lihat Gambar 2.2
11
Pemodelan sistem informasi analisis
desain
kode
tes
Gambar 2.2 Model Sekuensial Linear, Jogiyanto Pengenalan Komputer. .Edisi ke tiga Yogyakarta: Andi Yogyakarta
2.3 Model Waterfall Salah satu metodologi untuk merancang sistem-sistem perangkat lunak adalah model waterfall. Pendekatan model waterfall berupaya membangun suatu lingkungan yang sangat terstruktur di mana proses pengembangan dilaksanakan secara sekuensial. Model waterfall terdiri dari beberapa tahap yaitu : 1. Analisis Tahap pengembangan rekayasa perangkat lunak dimulai dengan analisis yang sasaran utamanya adalah mengidentifikasikan apa yang harus mampu dilaksanakan oleh system yang diajukan.
2. Perancangan Apabila analisis menitik beratkan pada apa yang harus mampu dilakukan oleh system yang diajukan. Perancangan menitik beratkan pada bagaimana sistem melakukan hal tersebut. Pada tahap inilah sistem perangkat lunak dirancang.
12
3. Implementasi Implementasi melibatkan penulisan aktual program – program, pembuatan berkas – berkas data, dan pengembangan basis data.
4. Pengujian Pengujian sangat terkait erat dengan implementasi, karena setiap modul system biasanya diuji ketika diimplementasikan.
5. Penggunaan dan modifikasi/perawatan Dalam penulisan Tugas Akhir ini, penulis tidak menyertakan tahap penggunaan dan perawatan karena pembuatan simulasi pengukur ketinggian air ini hanya sampai pada tahap pengujian. Gambar 2.3 memperlihatkan metodologi pengembangan rekayasa perangkat lunak model Waterfall (Brookshear, 2003:824).
Analisis
Pengembangan perangkat lunak Perancangan Implementasi Pengujian
Penggunaan
Perawatan
Gambar 2.3 Model Waterfall, Jogiyanto, Hartono. 2004. Pengenalan Komputer. Yogyakarta : Penerbit Andi
13
2.4
Pengenalan Unified Modelling Language (UML) Dalam suatu pengembangan perangkat lunak, analisa dan rancangan telah
merupakan terminoalogi yang sangat tua. Pada saat masalah ditelusuri dan spesifikasi dinegosiasikan, dapat dikatakan kita berada pada tahap rancangan. Merancang adalah menemukan suatu cara untuk menyelesaikan masalah, salah satu tool atau model untuk merancang pengembangan perangkat lunak yang berbasis object oriented adalah UML.
2.4.1 Sejarah Singkat UML UML (Unified Modelling Language) adalah sebuah bahasa yang berdasarkan grakfik atau gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan perangkat lunak 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 perangkat lunak. Pendekatan analisa dan rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi perangkat lunak sudah meningkat dan mulai komplek. Jumlah yang menggunakan metode OO mulai diuji cobakan dan 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 Jeneral Electric, dikenal dengan OMT (Object Modeling Technique). Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang 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 padabulan oktober 1994, ketika Rumbaugh bergabung Booch untuk membuat sebuah project pendekatan metoda yang uniform atau seragam dari masing-
14
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 standarstandar teknologi objectoriented dan software component.
2.4.2
Diagram UML UML tidak hanya merupakan sebuah bahasa pemrograman visual saja
namun juga dapat secara langsung 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. 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. Diagram pertama adalah use case menggambarkan sekelompok use cases dan aktor yang disertai dengan hubungan diantaranya. Diagram use cases ini menjelaskan dan menerangkan kebutuhan / requirement yang diinginkan atau dikehendaki user atau pengguna, serta sangat berguna dalam menentukan struktur organisasi dan model dari pada sebuah sistem. Unified Modeling Language (UML) adalah sebuah bahasa untuk menentukan, visualisasi, kontruksi, dan mendokumantasikan artifacts dari sistem perangkat lunak, untuk memodelkan bisnis, dan sistem non software lainnya. UML merupakan suatu kumpulan teknik terbaik yang telah terbukti sukses dalam
15
memodelkan sistem yang besar dan kompleks (Suhendar dan Gunardi, 2002:26). UML terdiri dari 13 jenis diagram resmi seperti tertulis dalam Tabel 2.1
Tabel 2.1 Jenis diagram resmi UML (Munawar. 2005). No.
Diagram
Kegunaan
1.
Activity
Prilaku prosedural dan paralel
2.
Class
Class, fitur, dan hubungan-hubungan
3.
Communication
Interaksi antar objek; penekanan pada jalur
4.
Component
Struktur dan koneksi komponen
5.
Composite Structure
Dekomposisi runtime sebuah class
6.
Deployment
Pemindahan artifact ke node
7.
Interaction overview
Campuran sequence dan activity diagram
8.
Object
Contoh configurasi dari contoh-contoh
9.
Package
Struktur hirarki compile-time
10.
Sequence
Interaksi antar objek; penekanan pada sequence
11.
State machine
Bagaimana event mengubah objek selama aktif
12.
Timing
Interaksi antar objek; penekanan pada timing
13.
Use Case
Bagaimana pengguna berinteraksi dengan sebuah sistem
2.4.3
Diagram Use Case Sebuah use case menggambarkan suatu urutan interaksi antara satu atau
lebih aktor dan sistem. Dalam fase requirements, model use case mengambarkan sistem sebagai sebuah kotak hitam dan interaksi antara aktor dan sistem dalam suatu bentuk naratif, yang terdiri dari input user dan respon-respon sistem. Setiap use case menggambarkan perilaku sejumlah aspek sistem, tanpa mengurangi struktur internalnya. Selama pembuatan model use case secara pararel juga harus ditetapkan obyek-obyek yang terlibat dalam setiap use case. 2.4.3.1 Aktor Sebuah aktor mencirikan suatu bagian outside user atau susunan yang berkaitan dengan user yang berinteraksi dengan sistem (Rumbaugh, Booch, dan Jacobson 1999). Dalam model use case, aktor merupakan satu-satunya kesatuan eksternal yang berinteraksi dengan sistem. Terdapat beberapa variasi bagaimana
16
aktor dibentuk (Fowler dan Scott 1999). Sebuah aktor sering kali merupakan manusia (human user). Pada sejumlah sistem informasi, manusia adalah satusatunya aktor. Dan mungkin saja dalam sistem informasi, seorang aktor bisa saja menjadi suatu sistem eksternal. Pada aplikasi real-time dan distribusi, sebuah aktor bisa saja menjadi satu perangkat eksternal I/O atau sebuah alat pengatur waktu. Perangkat eksternal I/O dan pengatur waktu aktor secara khusus lazimnya berada dalam real-time yang tersimpan dalam sistem (real-time embedded systems), sistem berinteraksi dengan lingkungan eksternal melalui sensor dan aktuator. Primary actor (aktor utama) memprakarsai sebuah use case. Jadi, suatu primary aktor memegang peran sebagai proaktif dan yang memulai aksi dalam sistem. Aktor lainnya yang berperan sebagai secondary aktor bisa saja terlibat dalam use case dengan menerima output dan memberikan input. Setidaknya satu aktor harus mendapatkan nilai dari use case. Biasanya adalah primary aktor (aktor utama). Bagaimanapun, dalam real-time embedded systems, primary aktor dapat berperan sebagai perangkat eksternal I/O atau pengatur waktu, penerima utama dari use case bisa menjadi secondary human aktor yang menerima sejumlah informasi dari sistem. Aktor manusia bisa saja menggunakan berbagai perangkat I/O untuk berinteraksi fisik dengan sistem. Aktor manusia dapat berinteraksi dengan sistem melalui perangkat standar I/O, seperti keyboard, display, atau mouse. Aktor manusia bisa juga berinteraksi dengan sistem melalui perangkat non-standar I/O seperti bermacam-macam sensor. Dalam keseluruhan hal tersebut, manusia merupakan aktor dan perangkat I/O adalah bukan aktor. Use case secara periodik diperlukan ketika beberapa informasi perlu dioutput oleh sistem pada suatu basis reguler. Hal ini sangat penting dalam sistemsistem real-time, dan juga sangat berguna dalam sistem informasi. Walaupun sejumlah metodologi menganggap pengukur waktu merupakan hal internal bagi sistem, dan akan lebih berguna dalam desain aplikasi real-time untuk memperhatikan pengukur-pengukur waktu sebagai eksternal logis bagi sistem dan menganggapnya sebagai primary aktor yang memulai aksi dalam sistem. Contohnya, pada sistem monitoring mobil, beberapa use case di-inisialisasi dengan suatu aktor pengukur waktu. Sebagai contoh dapat dilihat pada Gambar
17
2.4 Timer aktor mengawali Calculate Trip Speed use case, yang secara periodik menghitung rata-rata kecepatan melalui suatu jalan/ jejak dan menampilkan nilai ini ke driver. Dalam hal ini, pengukur waktu merupakan primary aktor (aktor utama) dan driver merupakan secondary aktor (aktor kedua).
Gambar 2.4 Contoh aktor pengukur waktu
Suatu aktor bisa juga menjadi sistem eksternal yang melakukan inisiatif (sebagai primary aktor) atau partisipan (sebagai secondary aktor) dalam use case. Satu contoh aktor sistem eksternal adalah pabrik robot dalam Automation System.Robot mengawali proses dengan use case Generate Alarm dan Notify, robot menggerakkan alarm conditions yang dikirim ke operator pabrik yang berkepentingan, yang telah terdaftar untuk menerima alarms. Dalam use case ini, robot merupakan primary aktor yang mengawali inisiatif use case, dan operator merupakan secondary aktor yang menerima alarms.
2.4.3.2 Identifikasi Use Case Sebuah use case dimulai dengan masukan/input dari seorang aktor. Use case merupakan suatu urutan lengkap kejadian-kejadian yang diajukan oleh seorang aktor, dan spesifikasi interaksi antara aktor dengan sistem. Use case yang sederhana hanya melibatkan satu interaksi/hubungan dengan sebuah aktor, dan use case yang lebih kompleks melibatkan beberapa interaksi dengan aktor. Use cases yang lebih kompleks juga melibatkan lebih dari satu aktor. Untuk menjabarkan use case dalam sistem, sangat baik bila dimulai dengan memperhatikan aktor dan actions/aksi yang mereka lakukan dalam sistem. Setiap use case menggambarkan suatu urutan interaksi antara aktor dengan sistem.
18
Sebuah use case harus memberikan sejumlah nilai pada satu aktor. Kemudian, kebutuhan fungsional sistem dijelaskan dalam use case yang merupakan suatu spesifikasi eksternal dari sebuah sistem. Bagaimanapun juga, ketika membuat use case, sangatlah penting menghindari suatu dekomposisi fungsional yang dalam beberapa use case kecil lebih menjelaskan fungsi-fungsi individual sistem dari pada menjelaskan urutan kejadian yang memberikan hasil yang berguna bagi aktor. Urutan utama use case menjelaskan urutan interaksi yang paling umum antara aktor dan sistem. Dan mungkin saja terdapat cabang-cabang urutan use case utama, yang mengarah pada berkurangnya frekuensi interaksi antara aktor dengan sistem. Deviasi-deviasi dari urutan utama hanya dilaksanakan pada beberapa situasi, contohnya jika aktor melakukan kesalahan input pada sistem. Ketergantungan pada aplikasi kebutuhan, alternatif ini memecahkan use case dan kadang-kadang bersatu kembali dengan urutan utama.
2.4.3.3 Pendokumentasian Model Use Case Use case didokumentasi dalam use case model sebagai berikut: • Use Case Name. Setiap use case diberi nama. • Summary. Deskripsi singkat use case, biasanya satu atau dua kalimat. • Dependency. Bagian ini menggambarkan apakah use case yang satu tergantung pada use case yang lain, dalam arti apakah use case tersebut termasuk pada use case yang lain atau malah memperluas use case lain. • Actors. Bagian ini memberikan nama pada actor dalam use case. Selalu terdapat use case utama (primary use case) yang memulai use case. Disamping itu terdapat juga secondary use case yang terlibat dalam use case. • Preconditions. Satu atau lebih kondisi harus berjalan dengan baik pada permulaan use case. • Deskripsi. Bagian terbesar dari use case merupakan deskripsi naratif dari urutan utama use case yang merupakan urutan yang paling umum dari interaksi antara aktor dan sistem. Deskripsi tersebut dalam bentuk input dari aktor, diikuti oleh respon pada sistem. Sistem ditandai dengan sebuah kotak hitam (black box) yang berkaitan dengan apa yang sistem lakukan dalam merespon input aktor, bukan bagaimana internal melakukannya.
19
• Alternatif-alternatif. Deskripsi naratif dari alternatif merupakan cabang dari urutan utama. Terdapat beberapa cabang alternatif dari urutan utama. Contohnya, jika rekening customer terdapat dana yang tidak sesuai, akan tampil permohonan maaf dan menolak kartu. •
Postcondition. Kondisi yang selalu terjadi di akhir use case, jika urutan
utama telah dilakukan; contohnya dana customer telah ditarik. •
Outstanding
questions.
Pertanyaan-pertanyaan
tentang
use
case
didokumentasikan untuk didiskusikan dengan para user. Diagram use case adalah menjelaskan mamfaat sistem jika dilihat menurut pandangan orang yang berada diluar sistem (aktor) diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem berinteraksi dengan dunia luar. Diagram Use Case dapat digunakan selama proses analisis untuk menangkap kebutuhan sistem dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, diagram Use Case menetapkan prilaku (Behavior) sistem saat dimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa diagram use case (Suhendar dan Gunadi, 2002:49). Berikut pada Tabel 2.2 adalah simbol-simbol yang sering digunakan pada saat pembuatan diagram use case.
Tabel 2.2 Notasi use case diagram (Booch, Rambaugh, dan Jacobson 1998)
No
Simbol
Keterangan
1
Actor
2
Use case
3
Batas sistem (sytem boundry)
4
Garis penghubung (pengendali arah)
20
5
Gabungan (association)
6
Generalisasi (generalization)
7
Relasasi (realization) << include>>
8
Stereotype penyertaan (Include)
<< extend >> 9
Stereotype perluasan (Extend)
Menurut Manuwar (2005:179) setiap use case harus di deskripsikan dalam dokumen yang disebut dengan dokumen aliran kejadian (flow of event). Dokumen ini mendefenisikan apa yang harus dilakukan oleh sistem ketika aktor mengaktifkan use case. Struktur dari dokumen use case ini bisa macam-macam, tetapi umumnya deskripsi ini paling tidak harus mengandung: 1. Deskripsi singkat (brief description). 2. Aktor yang hebat. 3. Kodisi awal (precondition) yang penting bagi use case untuk memulai. 4. Deskripsi rinci dari aliran kejadian yang mencakup: a. Aliran utama (main flow) dari kejadian yang bisa dirinci lagi. b. Aliran bagian (sub flow) dari kejadian. c. Aliran alternatif untuk mendefenisikan situasi perkecualian. 5 Kodisi akhir yang menjelaskan state dari sistem setelah use case berakhir. Dokumen use case ini berkembang selama masa pengembangan. Diawalawal penentuan kebutuhan sistem, hanya deskripsi singkat saja yang ditulis. Bagian-bagian lagi dari dokumen ini ditulis secara gradual dan interaktif. Akhirnya sebuah dokumen lengkap bisa di dapatkan di akhir fase spesifikasi. Biasanya pada fase spesifikasi ini sebuah prototipe yang dilengkapi dengan
21
tampilan layar bisa ditambahkan. Pada tahap berikut, dokumen use case ini bisa digunakan untuk membuat dokumentasi untuk implementasi sistem.
2.4.4. Diagram sekuensial (Sequence Diagram) Sebuah diagram sekuensial menjelaskan tentang interaksi objek yang disusun dalam suatu urutan waktu. Diagram ini secara khusus berasosiasi dengan diagram use case. Diagram sekuensial memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu di dalam use case (suhendar dan gunadi, 2002:51). Tabel 2.3 memperlihatkan notasi-notasi dalam pemodelan diagram sekuensial. Tabel 2.3 Notasi sequence diagram (Fowler, 2005) No.
Notasi
1
2
Keterangan
Aktor
Nama obyek
Obyek
3
Batas (Boundry)
4
Kendali (Control)
5
Entitas (Entity)
6
Penggerakan (Activation)
7
Garis hidup (Lifeline)
22
8
Pesan selaras (Synhcronous message)
Pesan tidak selaras (Asynhcronous
9
message)
Pesan kembali yang tidak selaras
10
(Asynhcronous return message)
11
Pesan rekrusif (Self message)
12
Pesan hilang (Lost message)
13
Pesan ditemukan (Found message)
New 14
Pesan pembuatan obyek baru
15
Pesan penghapusan obyek
23
2.4.5 Diagram aktifitas Diagram aktifiti adalah teknik untuk mendeskripsikan logika procedural, proses bisnis dan aliran kerja dalam banyak kasus. Diagram aktifitas mempunyai peran seperti halnya diagram alur (flowchart), akan tetapi perbedaannya dengan flowchart adalah diagram aktifitas mendukung prilaku parallel sedangkan flowchart tidak bias. Munawar (2005:109). Berikut pada Tabel 2.4 adalah symbolsimbol yang sering digunakan pada saat pembuatan diagram aktifitas.
Tabel 2.4 Simbol-simbol Pada Diagram Aktifitas. No
Simbol
Keterangan
1
Titik awal
2
Titik akhir
3
Activity
4
Pilihan untuk mengambil keputusan
Fork: digunakan untuk menunjukkan kegiatan 5
yang dilakukan secara parallel atau untuk menggabungkan dua kegiatan parallel menjadi satu
6
Rake: menunjukkan adanya dekomposisi
7
Tanda waktu
8
Tanda pengiriman
24
9
Tanda penerimaan
10
Aliran akhir (flow final)
Gambar 2.5 Contoh diagram activity (Pressman, 2005)
2.5
Mengenal Visual Basic 6.0 Visual Basic adalah salah satu bahasa pemrograman komputer yang sudah
mendukung OOP(Object Oriented Programming ) dan merupakan bahasa pemrograman berbasis GUI (Graphical User Interface ). Visual Basic adalah pengembangan dari bahasa pendahulunyayaitu bahasa pemrograman BASIC ( Beginner’s All Purpoe Symbolic Instruction Code ). VisualBasic merupakan salah satu alat bantu ( Development Tool ) dalam pembuatan berbagai macam program komputer, khususnya program komputer yang berbasis sistem operasi Windows menurut (Febryan Hari Purwanto.
[email protected]).
Microsof visual basic adalah bahasa pemrograman yang digunakan untuk membuat aplikasi Windows yang bergrafis (GUI-Graphical User Interface). Visual basic merupakan event-drivent programing (pemrograman terkendali kejadian) artinya program menunggu sampai adanya respon dari pemakai berupa/pengguna berupa event/kejadian tertentu (tombol diklik, menu dipilih, dan lain-lain).
25
2.5.1 Sejarah Singkat Visual Basic Berikut ini adalah point-point penting dalam sejarah perkembangan visual basic, sebagai berikut:
Visual basic pertama kali diperkenalkan tahun 1991 yaitu program visual basic untuk DOS dan untuk Windows.
Visual basic 3.0 dirilis tahun 1993.
Visual basic 4.0 dirilis pada akhir 1995 (tambahan dukungan untuk aplikasi 32 bit).
Visual basic terbaru adalah versi 6.0 yang dirilis pada akhir tahun 1998.
Microsoft unmumnya membuat tiga edisi visual basic yaitu:
Standard Edition merupakan produk dasar.
Profesional Edition berisi tambahan Microsoft Jet Data Access.
Enterprise Edition adalah edisi client-server.
2.5.2
IDE ( Integrated Development Environment ) Visual Basic 6.0 Langkah pertama dalam membuat program aplikasi dengan Visual Basic
6.0 adalah membuat sebuah project. Pembuatan sebuah project dapat dilakukan dengan beberapa cara, diantaranya dengan meng-klik Start | Program | Microsoft Visual Studio 6.0 | Microsoft Visual Basic 6.0. Setelah itu akan terlihat tampilan pilihan jenis New Project, pilih Standart EXE maka akan terlihat tampilan IDE (Integrated Development Environment) Visual Basic 6.0.
26
Gambar 2.5 Tampilan IDE Visual Basic 6.0
Gambar 2.6 IDE Visual Basic
1) Menu Visual Basic mempunyai tigabelas menu dan masing-masing menu mempunyai fungsi yang berbeda.
2) Toolbar Toolbar mempunyai fungsi yang sama dengan menu, hanya saja berupa icon-icon gambar dan digunakan sebagai jalan pintas. 3) Toolbox Toolbox merupakan tempat kontrol-kontrol yang akan digunakan untuk membantu pembuatan program aplikasi. 4) Project Explorer Project Explorer merupakan tempat yang digunakan untuk melihat daftar forms, modules, class modules, dan designers. 5) Properties Window Properties Window berfungsi untuk mengatur properti dari setiap objek kontrol atau form. Pada Properties Window semua objek kontrol dapat diatur karakteristiknya.
27
6) Form Layout Window Form layout window berfungsi untuk melihat atau mengetahui posisi tampilan form saat program dijalankan. 7) Form Objek Form objek digunakan untuk menempatkan atau meletakkan objek dari kontrol-kontrol yang akan digunakan untuk merancang dan membuat program aplikasi. 8) Form Kode Form kode digunakan sebagai tempat untuk menulis kode-kode program aplikasi
