2. RAD mengikut tahapan pengembangan system seperti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang
ada reuseable object sehingga pengembang tidak perlu membuat dari awal lagi dan waktu lebih singkat.
3. Memerlukan biaya yang lebih sedikit dan mementingkan dari segi bisnis dan teknik.
4. Berkonsentrasi pada sudut pandang user dan menyediakan perubahan secara cepat sesuai permintaan user.
5. Menghasilkan jarak kesesuaian yang kecil antara kebutuhan user dan spesifikasi sistem.
6. Waktu, biaya, dan effort minimal.
b. Kelemahan Model RAD Kendall dan Kendall, 2008
1. RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik
2. RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktivitas rapid-fire yang siperlukan untuk melengkapai sebuah
sistem, di dalam kerangka waktu yang sangat diperpendek. 3. Kecepatan yang tinggi dengan biaya minimal kemungkinan besar hasil
kualitasnya rendah. 4. Proyek mungkin berakhir dengan lebih banyak tambahan kebutuhan
daripada yang telah dipenuhi. 5. Potensial adanya penambahan fitur karena fitur yang sekarang hasilnya
asal-asalan. 6. Potensial ketidaksesuaian desain dan implementasi
7. Potensial ketidakkonsistenan penamaan dan dokumentasi 8. Sangat sulit membuat modul yang dapat digunakan kembali
c. Kondisi Sesuai RAD Kendall dan Kendall, 2008 1. Proyek dengan skala kecil sampai medium dengan waktu pendek
2. Fokus pada lingkup tertentu, misalnya pada objek bisnis yang telah didefiniskan dengan baik.
3. Bukan aplikasi dengan komputasi yang kompleks 4. User tahu pasti area yang harus dimiliki aplikasi
5. Manajemen memiliki komitmen terhadap keterlibatan user 6. Spesifikasi kebutuhan sudah benar-benar diketahui
7. Anggota tim memiliki keahlian yang baik 8. Komposisi tim stabil
9. Ada kontrol proyek yang efektif. d. Kondisi Tidak Sesuai RAD Kendall dan Kendall, 2008
1. Proyek yang terlalu besar dan kompleks 2. Proyek yang bersifat aplikasi real-time atau menangani hal-hal kritis
3. Sistem dengan komputasi tinggi 4. Lingkup dan objek bisnis proyek belum jelas
5. Pengumpulan spesifikasi kebutuhan membutuhkan waktu lama 6. Banyak orang yang harus terlibat dalam proyek
7. Membutuhkan lingkup daerah yang luas
8. Tim proyek besar dengan koordinasi tinggi 9. Komitmen pihak manajemen dengan user rendah
10. Banyak teknologi baru digunakan untuk membangun aplikasi.
2.7 Alat Bantu Perancangan Sistem
Unified Modeling Language UML
Unified Modeling Language UML adalah satu kumpulan konvensi pemodelan yang di gunakan untuk menentukan atau menggambarkan sebuah
sistem software yang terkait dengan objek Whitten dan Bentley, 2008.
2.7.1 Notasi UML
Unifield modeling language UML adalah keluarga notasi grafis yang didukung oleh meta
–model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan
pemrograman berorientasi objek OO Whitten dan Bentley, 2008. Diagram UML terdiri dari :
1. Use Case Diagram
Use case diagram secara grafis menggambarkan interaksi antara system, system eksternal, dan pengguna. Dengan kata lain, secara grafis mendeskripsikan
siapa yang akan menggunakan system dan dalam cara apa pengguna mengharapkan interaksi dengan system itu. Use case naratif digunakan untuk
secara tekstual menggambarkan sekuensial langkah-langkah dari setiap interaksi.
Tabel 2.1 Notasi Use Case Diagram Whitten dan Bentley, 2008
Notasi Keterangan
Actor
Actor adalah segala sesuatu yang perlu berinteraksi dengan sistem
untuk pertukaran informasi. Bisa merupakan manusia, sistem atau
device
Use case
Mengidentifikasi fitur kunci dari sistem. Tanpa fitur ini,
sistem tidak akan memenuhi permintaan useraktor. Setiap
use case mengekspresikan goal dari sistem yang harus dicapai.
Diberi nama sesuai dengan goalnya
dan digambarkan
dengan elips dan nama di dalamnya.
Association
Mengidentifikasikan interaksi antara setiap actor tertentu
dengan setiap use case tertentu. Digambarkan
sebagai garis
antara actor terhadap use case yang bersangkutan.
Extends
Menspesifikasikan bahwa use case target memperluas prilaku
dari use case sumber secara eksplisit
Uses includes
Mengidentifikasi kelakuan
yang harus terpenuhi agar sebuah event dapat terjadi,
kondisi ini adalah hubungan dua use case dimana yang satu
memanggil yang lain.
Actor1
«uses» «extends»
Gambar 2.10 Use Case Diagram Whitten dan Bentley, 2008
Contoh kasus penggunaan Use Case Diagram:
Login
Penilaian Kinerja Absensi
Validasi gaji Lihat penilaian kinerja
Lihat absensi
Admin Eksekutif
Manajer Keuangan
Pegawai extends
extends
extends
Cetak slip gaji
Sistem Informasi Penggajian dan Penilaian Kinerja
Lihat laporan Gaji extends
Manajemen data pegawai
Lihat data pegawai
extends Logout
include
Gambar 2.11 Contoh kasus penggunaan Use Case Diagram
Use Case di atas terdiri dari 4 aktor dan 11 use case. Aktor berupa Admin, Eksekutif, Manajer Keuangan dan Pegawai. Use case terdiri dari login, logout,
manajemen data pegawai, lihat data pegawai, absensi, lihat absensi, penilaian kinerja, lihat penilaian kinerja, validasi gaji, lihat laporan gaji, serta cetak slip
gaji. garis dari aktor ke use case disebut asosiasi dimana menggambarkan interaksi aktor terhadap use case.
Include mengidentifikasi kelakuan yang harus terpenuhi agar sebuah event dapat terjadi. Pada contoh di atas terdapat use case logout include kepada use case
login, yang artinya untuk melakukan logout, use case login harus dilakukan terlebih dahulu.
Extend menspesifikasikan bahwa use case target memperluas prilaku dari use case sumber secara eksplisit. Pada contoh di atas salah satu contoh
penggunaan extend yaitu pada use case absensi dan lihat absensi dimana lihat absensi merupakan extend dari use case absensi, dimana use case lihat absensi
merupakan perluasan dari use case absensi.
2. Class Diagram
Class Diagram merupakan kumpulan class dan object. Oleh karena itu pengertian class sangat penting sebelum merancang class diagram. Whitten et al.
2004 dalam buku Widodo dan Herlawati 2011 mengartikan class sebagai satu set objek yang memiliki atribut dan perilaku yang sama. Class terkadang disebut
sebagai kelas objek object class. Secara alami, objek yang berupa buku analisis
desain dan buku pemrograman kita kelompokan dalam satu kelas, yaitu kelas buku. Widodo dan Herlawati, 2011
Secara teknis, Pender dan Tom 2003 dalam buku Widodo dan Herlawati 2011 mengartikan sebuah kelas sebagai suatu definisi sumber daya yang
termasuk di dalamnya informasi-informasi yang menggambarkan fitur suatu entitas dan bagaiman penggunaannya. Sedangkan objek adalam entitas yang
bersifat unik yang mengikuti aturan-aturan yang sudah didefinisikan dalam kelasnya. Kelas menggambarkan suatu kelompok yang memiliki kesamaan
keadaan dan perilaku. Kelas merupakan cetak biru suatu objek dalam sistem orientasi objek. Dapat dikatakan kelas adalah sejenis alat pengklasifikasi.
Visibility atau Ketampakan digunakan untuk menspesifikasikan ketampakan atribut dan operasi dari kelas-kelas lain. UML mengadopsi
ketampakan di C++, yaitu
1. Public
, disimbolkan dengan “+”, dapat diakses operasi-operasi di luar kelas.
2. Protected, disimbolkan
dengan “”, hanya dapat diakses operasi- operasi di kelas dan kelas-kelas turunannya.
3. Private
, disimbolkan dengan “-“, hanya dapat diakses operas-operasi di kelas.
Tabel 2.2 Notasi Class Diagram Whitten dan Bentley, 2008
Notasi Keterangan
Class 1.
class name 2.
attributes 3.
behaviors Association
Hubungan statis antar class. Umumnya menggambarkan class yang memiliki
atribut berupa class lain, atau class yang
harus mengetahui eksistensi class lain Agregation
Hubungan yang menyatakan “bagian dari”, “bagian keseluruhan” atau “terdiri
atas” Generalization
Menggambarkan hubungan
khusus dalam
objek anakchild
yang
menggantikan objek parentinduk
Multiplisitaskardinalitas
Kita dapat menentukan kemunculan objek suatu kelas di suatu keterhubungan dengan kelas lain.
1
Class
1 2
3
Multiplisitas mengimplikasikan hubungan antara instansi, contohnya satu Employee mempunyai satu objek TimeCard atau lebih. Namun, satu
TimeCard milik satu Employee yaitu Employee-employee tidak menggunakan satu kartu yang sama Hariyanto, 2004. Beberapa
multiplisitas yang banyak kita lihat Fowler, 2005, diantaranya:
1 menyatakan 1 Employee hanya boleh memiliki 1 TimeCard 0..1 menyatakan 1 Employee memiliki atau boleh tidak memiliki
TimeCard
menyatakan bahwa Employee boleh memiliki lebih dari 1
TimeCard
Gambar 2.12 Asosiasi Class Diagram Hariyanto, 2004
Contoh kasus Class Diagram:
+add +edit
data_pegawai
-nip -nama
-tgl_kerja -jabatan
-alamat -kota
-tpt_lahir -tgl_lahir
-gender -telp
-email -agama
-sts_kawin -jml_anak
+Login +Edit
user
-id_user -nip
-username -password
-level 1..
1 +Create
penggajian
-id_gaji -nip
-periode_gaji -gaji_pokok
-tunjangan_nikah -tunjangan_anak
-kinerja -potongan_gaji
-total_gaji -status
1 1..
+Add +View
+Cetak
absensi
-id_absensi -nip
-periode -keterangan
-jam_masuk -jam_keluar
1 1..
+Create +Update
penilaian_kinerja
-id_penilaian -nip
-periode_penilaian -tepat_waktu
-penampilan -tanggung_jawab
-kerapihan_kerja -inisiatif
-catatan -hasil
1 1..
+add +edit
+delete +cetak
admin
-level
+View +Cetak
eksekutif
-level +View
+Validasi
keuangan
-level
+Absen
pegawai
-level 1
Gambar 2.13 Contoh kasus penggunaan Class Diagram
Contoh di atas terdiri dari 9 class dimana 4 class merupakan generalisasi dari 1 class. Class terdiri dari Class Name, Attributes, dan Behaviour. Pada class
user memiliki atribut id_user, nip, username, password, dan level dan behaviour login dan edit. Masing-masing class memiliki hubungan antar class yang lain.
Setiap asosiasi memiliki multiplisitas, seperti hubungan antara data_pegawai dengan penggajian. Hubungan tersebut menjelaskan bahwa 1 data_pegawai dapat
memiliki 1 atau banyak penggajian, sedangkan 1 penggajian hanya dimiliki 1 data_pegawai.
3. Activity Diagram
Activity diagram secara grafis digunakan untuk menggambarkan rangkaian aliran aktivitas baik proses bisnis atau use case. Diagram ini juga dapat digunakan
untuk memodelkan action yang akan dilakukan saat sebuah operasi dieksekusi, dan memodelkan hasil dari action tersebut.
Tabel 2.3 Notasi Activity Diagram Whitten dan Bentley, 2008
Notasi Keterangan
Activity adalah
langkah-langkah dalam sebuah activity.
Action bisa terjadi saat memasuki
activity, meninggalkan
activity, atau pada event yang
spesifik.
Initiate Activities Menujukkan alur activity
berjalan
Start of the Process Menujukkan
dimana
aliran kerja itu di mulai. Termination
of the
Process Menujukkan
dimana
aliran kerja itu berakhir Synchronization Bar
menunjukkan dua atau lebih
langkah dalam
aliran kerja
berjalan
secara serentak. Decision Activity
Menunjukkan dimana
sebuah keputusan perlu di buat dalam aliran kerja.
Contoh kasus penggunaan Activity Diagram:
Sistem Admin
Memilih menu Data pegawai Menampilkan Halaman
Data Pegawai Pilih menu tindakan
Edit Hapus
Tambah Menampilkan form tambah pegawai
Input data pegawai
Menampilkan data pegawai Ubah data pegawai
Tampilkan pesan hapus data pegawai
Hapus data pegawai
Menyimpan ke database
Valid Tidak
valid Tidak
valid Valid
Pilih Hapus Mengubah
data pegawai
Gambar 2.14 Contoh kasus penggunaan Activity Diagram
Contoh di atas merupakan contoh activity dalam memanajemen data pegawai. Aktivitas dimulai admin memilih menu Data Pegawai. Synchronization
bar berfungsi untuk memisahkan 2 atau lebih aktivitas. Pada kasus di atas terdapat 3 aktivitas yaitu tambah edit dan hapus. Lalu sistem akan merespon dan admin
memilih tindakan. Proses berjalan dari validasi data yang di input hingga proses penyimpanan data.
4. Sequence Diagram
Sequence diagram secara grafis menggambarkan bagaimana objek berinteraksi dengan satu sama lain melalui pesan pada eksekusi sebuah use case
atau operasi. Diagram ini mengilustrasikan bagaimana pesan terkirim dan diterima diantara objek dan dalam sekuensi apa Whitten dan Bentley, 2008.
Tabel 2.4 Notasi Sequence Diagram Whitten dan Bentley, 2008
Simbol Keterangan
Boundary Biasanya berupa tepi dari sistem, seperti user
interface atau suatu alat yang berinteraksi dengan sistem lain
Activation Merupakan periode yang dibutuhkan saat
melakukan operasi.
Actor1
Merepresentasikan entitas yang berada di luar sistem,mereka bisa berupa manusia, atau
perangkat sistem lain.
Message1
Relasi ini digunakan untuk memanggil operasi atau metode yang dimiliki oleh suatu
objek. Message
mengharuskan kita
menyelesaikan proses
baru kemudian
memanggil proses berikutnya.
Message2
Relasi ini menunjukkan bahwa suatu objek hendak memanggil dirinya sendiri.
Gambar 2.15 Sequence Diagram Kendall dan Kendall, 2008
Contoh kasus penggunaan Sequene Diagram:
::Class Object::Class
Method parameter Return
AsynchronousSignal
Manajemen data pegawai Admin
Data_Pegawai
Memilih menu Data pegawai Meminta data pegawai
Mendapatkan data Pegawai Memilih menu Tambah
Menampilkan data Pegawai Menampilkan form Tambah pegawai
Mengisi form Tambah pegawai Memilih menu Edit
Menampilkan form data pegawai Mengubah form data pegawai
Memilih menu Hapus Menampilkan pesan konfirmasi hapus
Tekan Hapus User
Menyimpan data Menyimpan data
Mengubah data
Menghapus data Menghapus data
Gambar 2.16 Contoh kasus penggunaan Sequence Diagram
Contoh di atas merupakan contoh sequence diagram dalam proses manajemen data pegawai. Proses dimulai admin memilih menu data pegawai lalu
sistem merespon menampilkan beberapa pilihan. Aksi tambah diawali dengan mengisi form data pegawai lalu diakhiri dengan menyimpan data pada data
pegawai dan user.
2.8 Mapping Problem Domain Object to an RDBMS Format
