Embed Size (px)
DESCRIPTION
client server gituh deh
Citation preview
IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-
CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)
Skripsi
Oleh: Yulianti
2009140661
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK
UNIVERSITAS PAMULANG JAKARTA
2013
IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-VIEW-
CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)
Skripsi
Diajukan Untuk Melengkapi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer
Oleh: Yulianti
2009140661
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK
UNIVERSITAS PAMULANG JAKARTA
2013
ii
LEMBAR PERNYATAAN
Yang bertanda tangan di bawah ini:
Nama : YULIANTI
NIM : 2009140661
Program Studi : Teknik Informatika
Fakultas : Teknik
Jenjang Pendidikan : Strata 1
Menyatakan bahwa skripsi yang saya buat dengan judul:
IMPLEMENTASI ARSITEKTUR CLIENT-SERVER DAN MVC (MODEL-
VIEW-CONTROLLER) UNTUK MEMBANGUN APLIKASI ADMINISTRASI
SEKOLAH (STUDI KASUS: SMK AVERUS JAKARTA)
1. Merupakan hasil karya tulis ilmiah sendiri, bukan merupakan karya yang
pernah diajukan untuk memperoleh gelar akademik oleh pihak lain, dan
bukan merupakan hasil plagiat.
2. Saya ijinkan untuk dikelola oleh Universitas Pamulang sesuai dengan
norma hukum dan etika yang berlaku.
Pernyataan ini saya buat dengan penuh tanggung jawab dan saya bersedia
menerima konsekuensi apapun sesuai aturan yang berlaku apabila di kemudian
hari pernyataan ini tidak benar.
Pamulang, 16 September 2013
( Yulianti )
iii
LEMBAR PERSETUJUAN
NIM : 2009140661
Nama : YULIANTI
Program Studi : TEKNIK INFORMATIKA
Fakultas : TEKNIK
Jenjang Pendidikan : STRATA 1
Judul Skripsi : IMPLEMENTASI ARSITEKTUR CLIENT-SERVER
DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK
MEMBANGUN APLIKASI ADMINISTRASI
SEKOLAH (STUDI KASUS: SMK AVERUS
JAKARTA)
Skripsi ini telah diperiksa dan disetujui.
Pamulang, 26 Agustus 2013
iv
LEMBAR PENGESAHAN
NIM : 2009140661
Nama : YULIANTI
Program Studi : TEKNIK INFORMATIKA
Fakultas : TEKNIK
Jenjang Pendidikan : STRATA 1
Judul Skripsi : IMPLEMENTASI ARSITEKTUR CLIENT-SERVER
DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK
MEMBANGUN APLIKASI ADMINISTRASI
SEKOLAH (STUDI KASUS: SMK AVERUS
JAKARTA)
Skripsi ini telah dipertahankan di hadapan dewan penguji ujian skripsi fakultas
Teknik, program studi Teknik Informatika dan dinyatakan LULUS.
Pamulang, 13 September 2013
v
KATA PENGANTAR
Puji dan syukur saya panjatkan kepada Allah SWT, karena atas berkah dan
rahmat-Nya, Maka skripsi yang berjudul ‘‘IMPLEMENTASI ARSITEKTUR
CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK
MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS:
SMK AVERUS JAKARTA)’’ dapat terselesaikan dengan baik.
Dalam penulisan Skripsi ini, banyak hambatan dan kesulitan yang penulis
hadapi, akan tetapi atas bantuan dan dorongan dari berbagai pihak, maka akhirnya
penulis dapat menyelesaikan skripsi ini. Untuk itu, pada kesempatan ini penulis
ingin menyampaikan rasa terima kasih yang sebesar-besarnya kepada:
1. Bapak Dr. H. Dayat Hidayat, M.M., selaku Rektor Universitas Pamulang.
2. Bapak Ir. Sewaka, M.M., selaku Dekan Fakultas Teknik Universitas
Pamulang.
3. Bapak Achmad Hindasyah, S.Si., M.Si., selaku Kepala Program Studi
Teknik Informatika Universitas Pamulang.
4. Ibu Normalisa, S.Kom., M.Kom., selaku dosen pembimbing, yang
memberikan bimbingan dengan baik, serta motivasi untuk segera
menyelesaikan skripsi ini.
5. Bapak Drs. H. A. Syarif AM, M.Pd., selaku kepala SMK (Sekolah
Menengah Kejuruan) Averus Jakarta, yang telah membantu memberikan
data-data yang diperlukan dalam menyelesaikan skripsi ini.
6. Kedua orang tua tersayang yang selalu memberi dorongan dan semangat
sehingga anakmu yang manja ini dapat menyelesaikan skripsi ini dengan
baik.
7. Suami tercinta yang selalu memberi dorongan dan semangat sehingga
istrimu tersayang ini dapat menyelesaikan skripsi ini dengan baik.
8. Seluruh pihak yang memberikan bantuan secara langsung maupun tidak
langsung yang tidak saya sebutkan satu-persatu.
Akhirnya dengan kerendahan hati, penulis menyadari bahwa banyak
kekurangan yang terdapat dalam penyusunan ini, sehingga masih jauh dari
sempurna yang disebabkan oleh beberapa keterbatasan dalam diri penulis. Oleh
kerena itu, penulis terbuka terhadap berbagai kritik dan saran yang bersifat
membangun bagi kesempurnaan skripsi ini.
Pamulang, 16 September 2013
Penulis
vi
ABSTRACT
Not many schools are implementing information technology to support
administrative processing. SMK (vocational high school) located AVERUS
Jakarta Pondok Pinang, South Jakarta is one of the educational institutions that do
not use information technology effectively and efficiently in administrative data
processing, administration partly because the data are recorded and processed
manually, although there has been recorded and processed using computer
applications using Microsoft Excel. This causes some problems such as, much
duplication of data, because each saved document has its own corresponding
importance of master data. The papers are not organized very well because the
data and stored according to the interests of each staff responsible
jawab.Pembuatan reports from administrative data tend to be slow, because it has
not been well integrated. Good application should be easily adapted to the needs
in the future.
To solve these problems, the school administration application built using a
client server architecture and MVC (Model View Controller). Because to build a
good system should use a good model. Client-server architecture can be used to
build a centralized application that can reduce the duplication of data / documents
and be able to improve organizational documents. Client-server architecture
divides the application into two parts, the server associated with database
management, and related client user interface. While the MVC architecture to
facilitate the development of applications in accordance with the requirements in
the future, and can reduce the amount of source code.
Administrative applications created using client server architecture and
MVC can solve the problems that exist. These applications can reduce the
duplication of data, organizations can improve data / documents, can accelerate
the creation of required reports, and can improve the efficiency and effectiveness
of application development.
Keywords: School Administration, Client-Server, MVC (Model-View-Controller)
xvi+120 pages; 79 figures; 17 tables; attachments; technical documentation
Bibliography: 32 (1994-2012)
vii
ABSTRAK
Belum banyak sekolah yang mengimplementasikan teknologi informasi
untuk menunjang pengolahan administrasinya. SMK (Sekolah Menengah
Kejuruan) AVERUS JAKARTA yang terletak Pondok Pinang, Jakarta Selatan
merupakan salah satu institusi pendidikan yang belum menggunakan teknologi
informasi secara efektif dan efisien dalam pengolahan data administrasinya,
karena data administrasinya sebagian dicatat dan diolah secara manual, walaupun
sudah ada yang dicatat dan diolah menggunakan aplikasi komputer menggunakan
Microsoft Excel. Hal ini menyebabkan beberapa masalah seperti, banyak terjadi
duplikasi data, karena setiap dokumen yang disimpan memiliki master data
tersendiri sesuai kepentingannya. Dokumen-dokumennya tidak teroganisir dengan
baik karena disimpan sesuai kepentingan datanya dan masing-masing staf yang
bertanggung jawab.Pembuatan laporan-laporan dari data-data administrasi
cenderung lambat, karena belum terintegrasi dengan baik. Aplikasi yang baik
harus mudah disesuaikan dengan kebutuhan di masa yang depan.
Untuk menyelesaikan permasalahan tersebut, maka dibangun aplikasi
administrasi sekolah menggunakan arsitektur client server dan MVC (Model View
Controller). Karena untuk membangun sistem yang baik harus menggunakan
model yang baik. Arsitektur client-server dapat digunakan untuk membangun
aplikasi terpusat yang dapat mengurangi duplikasi data/dokumen dan dapat
memperbaiki organisasi dokumen. Arsitektur client-server membagi aplikasi
dalam dua bagian, yaitu server yang berhubungan dengan pengelolaan basis data,
dan client yang berhubungan dengan antarmuka user. Sedangkan arsitektur MVC
dapat mempermudah pengembangan aplikasi sesuai dengan kebutuhan di masa
depan, dan dapat mengurangi jumlah source code.
Aplikasi administrasi yang dibuat menggunakan arsitektur client server dan
MVC dapat menyelesaikan permasalahan-permasalahan yang ada. Aplikasi ini
dapat mengurangi duplikasi data, dapat memperbaiki organisasi data/dokumen,
dapat mempercepat pembuatan laporan yang diperlukan, dan dapat meningkatkan
efisiensi dan efektifitas pengembangan aplikasi.
Kata kunci: Administrasi Sekolah, Client-Server, MVC (Model-View-Controller)
xvi+120 halaman; 79 gambar; 17 tabel; lampiran; 1 dokumentasi teknis
Daftar acuan: 32 (1994-2012)
viii
DAFTAR ISI
HALAMAN JUDUL ...................................................................................... i
LEMBAR PERNYATAAN .......................................................................... ii
LEMBAR PERSETUJUAN ......................................................................... iii
LEMBAR PENGESAHAN .......................................................................... iv
KATA PENGANTAR ................................................................................... v
ABSTRACT ................................................................................................... vi
ABSTRAK ................................................................................................... vii
DAFTAR ISI .............................................................................................. viii
DAFTAR GAMBAR ................................................................................... xii
DAFTAR TABEL ....................................................................................... xv
DAFTAR SIMBOL .................................................................................... xvi
DAFTAR LAMPIRAN .............................................................................. xix
BAB I PENDAHULUAN ......................................................................... 1
1.1 Latar Belakang............................................................................... 1
1.2 Identifikasi Masalah ...................................................................... 3
1.3 Tujuan ............................................................................................ 4
1.4 Batasan .......................................................................................... 4
1.5 Manfaat .......................................................................................... 4
1.6 Metodologi .................................................................................... 5
1.7 Sistematika Penulisan .................................................................... 6
BAB II LANDASAN TEORI .................................................................... 7
2.1 Implementasi ................................................................................. 7
2.2 Membangun Aplikasi .................................................................... 7
2.3 Administrasi Sekolah..................................................................... 8
2.3.1 Administrasi ............................................................................... 8
ix
2.3.2 Administrasi Sekolah ................................................................. 9
2.4 Arsitektur Client-Server .............................................................. 10
2.4.1 Kelebihan Client-Server .......................................................... 12
2.4.2 Kekurangan Client-Server ....................................................... 12
2.5 Basis Data (Database) ................................................................. 12
2.5.1 ERD (Entity Relationship Diagram)........................................ 13
2.5.2 Transformasi ERD ke LRS ...................................................... 15
2.5.3 Normalisasi .............................................................................. 16
2.6 Pengembangan Aplikasi .............................................................. 21
2.6.1 Siklus Hidup Pengembangan Aplikasi .................................... 22
2.6.2 Model Pengembangan Aplikasi ............................................... 24
2.7 Pemrograman Berorientasi Objek ............................................... 31
2.7.1 Prinsip-prinsip Pemrograman Berorientasi Objek ................... 32
2.7.2 Bahasa Pemrograman Berorientasi Objek ............................... 33
2.7.3 Desain Pemrograman Berorientasi Objek................................ 34
2.8 MVC (Model-View-Controller)................................................... 39
2.9 Pengujian (Testing) ...................................................................... 41
2.9.1 Tujuan Pengujian ..................................................................... 41
2.9.2 Jenis Pengujian ........................................................................ 42
2.9.2.1 Pengujian Black Box ......................................................... 42
2.9.2.2 Pengujian White Box ......................................................... 45
2.10 Aplikasi Pendukung..................................................................... 46
2.10.1 Java ........................................................................................ 46
2.10.1.1 Karakteristik Java ............................................................ 46
2.10.1.2 Sistem Kerja Java ............................................................ 48
2.10.1.3 Teknologi Java ................................................................ 49
x
2.10.2 NetBeans ................................................................................ 51
2.10.3 MySQL .................................................................................. 51
2.10.3.1 Kelebihan MySQL .......................................................... 52
2.10.3.2 Kekurangan MySQL ....................................................... 55
BAB III ANALISA DAN PERANCANGAN ....................................... 56
3.1 Analisa ......................................................................................... 56
3.1.1 Analisa Sistem Saat Ini ............................................................ 56
3.1.2 Analisa Data/Dokumen ............................................................ 57
3.1.3 Analisa Kebutuhan ................................................................... 58
3.2 Perancangan ................................................................................. 58
3.2.1 Perancangan Database (Basis Data) ........................................ 59
3.2.1.1 ERD (Entity Relationship Diagram) ................................. 59
3.2.1.2 ERD ke LRS ..................................................................... 61
3.2.1.3 LRS (Logical Record Structure) ....................................... 62
3.2.1.4 Normalisasi ....................................................................... 63
3.2.1.5 Spesifikasi Basis Data ....................................................... 63
3.2.2 Perancangan Aplikasi .............................................................. 68
3.2.2.1 Use Case Diagram ............................................................ 68
3.2.2.2 Sequence Diagram ............................................................ 72
3.2.2.3 Activity Diagram ............................................................... 83
3.2.2.4 Class Diagram ................................................................ 105
3.2.2.5 User Interface (Antarmuka Pengguna) ........................... 106
BAB IV IMPLEMENTASI DAN PENGUJIAN ................................. 109
4.1 Implemantasi ............................................................................. 109
4.1.1 Implementasi Basis Data ....................................................... 109
4.1.2 Implementasi Aplikasi ........................................................... 111
xi
4.2 Pengujian ................................................................................... 118
4.2.1 Pengujian Black Box .............................................................. 118
4.2.2 Pengujian White Box ............................................................. 120
4.3 Analisa ....................................................................................... 123
BAB V PENUTUP ................................................................................. 125
5.1 Kesimpulan ................................................................................ 125
5.2 Saran .......................................................................................... 125
DAFTAR PUSTAKA ................................................................................ 126
xii
DAFTAR GAMBAR
Gambar 2. 1 Hubungan antara client dengan server ................................... 12
Gambar 2. 2 Jenis diagram resmi UML 2.................................................... 35
Gambar 2. 3 Model MVC (Model View Controller) ................................... 40
Gambar 2. 4 Proses dari sebuah Program Java ............................................ 48
Gambar 2. 5 Java Cross-platform atau Multi-platform ............................... 49
Gambar 3. 1 Diagram activity sistem saat ini .............................................. 57
Gambar 3. 2 ERD basis data administrasi sekolah ...................................... 60
Gambar 3. 3 ERD ke LRS basis data administrasi sekolah ......................... 61
Gambar 3. 4 LRS basis data administrasi sekolah ....................................... 62
Gambar 3. 5 Use case diagram aplikasi administrasi sekolah .................... 69
Gambar 3. 6 Paket use case diagram akses aplikasi ................................... 70
Gambar 3. 7 Paket use case diagram master data ....................................... 70
Gambar 3. 8 Paket use case diagram transaksi ........................................... 71
Gambar 3. 9 Paket use case diagram laporan ............................................. 71
Gambar 3. 10 Sequence diagram login........................................................ 72
Gambar 3. 11 Sequence diagram logout...................................................... 72
Gambar 3. 12 Sequence diagram mengelola jenis persyaratan ................... 73
Gambar 3. 13 Sequence diagram mengelola jenis pembayaran .................. 73
Gambar 3. 14 Sequence diagram mengelola data staf administrasi ............ 74
Gambar 3. 15 Sequence diagram mengelola data guru ............................... 74
Gambar 3. 16 Sequence diagram mengelola data siswa ............................. 75
Gambar 3. 17 Sequence diagram mengelola kelompok mata pelajaran ...... 75
Gambar 3. 18 Sequence diagram mengelola mata pelajaran ....................... 76
Gambar 3. 19 Sequence diagram mengelola data jam ................................ 76
Gambar 3. 20 Sequence diagram mengelola data jurusan ........................... 77
Gambar 3. 21 Sequence diagram mengelola data kelas .............................. 77
Gambar 3. 22 Sequence diagram mengelola data kelas siswa .................... 78
Gambar 3. 23 Sequence diagram mengelola data pendaftaran.................... 78
Gambar 3. 24 Sequence diagram diagram proses penerimaan siswa .......... 79
xiii
Gambar 3. 25 Sequence diagram mengelola data pembayaran ................... 79
Gambar 3. 26 Sequence diagram mengelola jadwal ................................... 80
Gambar 3. 27 Sequence diagram mengelola data nilai ............................... 81
Gambar 3. 28 Sequence diagram mencetak laporan penerimaan siswa ...... 82
Gambar 3. 29 Sequence diagram mencetak laporan pembayaran ............... 82
Gambar 3. 30 Sequence diagram mencetak laporan nilai ........................... 83
Gambar 3. 31 Sequence diagram mencetak laporan jadwal ........................ 83
Gambar 3. 32 Activity diagram login .......................................................... 84
Gambar 3. 33 Activity diagram logout ........................................................ 84
Gambar 3. 34 Activity diagram mengelola jenis persyaratan ...................... 85
Gambar 3. 35 Activity diagram mengelola jenis pembayaran ..................... 86
Gambar 3. 36 Activity diagram mengelola data staf administrasi ............... 87
Gambar 3. 37 Activity diagram mengelola data guru .................................. 88
Gambar 3. 38 Activity diagram mengelola data siswa ................................ 89
Gambar 3. 39 Activity diagram mengelola kelompok mata pelajaran......... 90
Gambar 3. 40 Activity diagram mengelola mata pelajaran.......................... 91
Gambar 3. 41 Activity diagram mengelola data jam ................................... 92
Gambar 3. 42 Activity diagram mengelola data jurusan ............................. 93
Gambar 3. 43 Activity diagram mengelola data kelas ................................. 94
Gambar 3. 44 Activity diagram mengelola data kelas siswa ....................... 95
Gambar 3. 45 Activity diagram mengelola data pendaftaran ...................... 96
Gambar 3. 46 Activity diagram proses penerimaan siswa ........................... 97
Gambar 3. 47 Activity diagram mengelola data pembayaran ...................... 98
Gambar 3. 48 Activity diagram mengelola jadwal ...................................... 99
Gambar 3. 49 Activity diagram mengelola data nilai ................................ 100
Gambar 3. 50 Activity diagram mencetak laporan penerimaan siswa ....... 101
Gambar 3. 51 Activity diagram mencetak laporan pembayaran ................ 102
Gambar 3. 52 Activity diagram mencetak laporan nilai ............................ 103
Gambar 3. 53 Activity diagram mencetak laporan jadwal ......................... 104
Gambar 3. 54 Class diagram aplikasi administrasi sekolah ...................... 105
Gambar 3. 55 Desain antarmuka form utama ............................................ 106
Gambar 3. 56 Desain antarmuka form login ............................................. 106
xiv
Gambar 3. 57 Desain antarmuka informasi aplikasi .................................. 107
Gambar 3. 58 Desain antarmuka master data jenis persyaratan ................ 107
Gambar 3. 59 Desain antarmuka master data jenis pembayaran ............... 108
Gambar 4. 1 Diagram relasi basis data administrasi sekolah .................... 110
Gambar 4. 2 Tampilan form deskripsi ....................................................... 111
Gambar 4. 3 Tampilan form login ............................................................. 111
Gambar 4. 4 Tampilan form utama............................................................ 112
Gambar 4. 5 Tampilan form siswa ............................................................ 112
Gambar 4. 6 Tampilan form guru .............................................................. 113
Gambar 4. 7 Tampilan form staf administrasi ........................................... 113
Gambar 4. 8 Tampilan form pendaftaran .................................................. 114
Gambar 4. 9 Tampilan form penerimaan siswa ......................................... 114
Gambar 4. 10 Tampilan form pembayaran ................................................ 115
Gambar 4. 11 Tampilan form jadwal ......................................................... 115
Gambar 4. 12 Tampilan form nilai ............................................................ 116
Gambar 4. 13 Tampilan form laporan penerimaan siswa .......................... 116
Gambar 4. 14 Tampilan form laporan nilai ............................................... 117
Gambar 4. 15 Tampilan form laporan pembayaran ................................... 117
Gambar 4. 16 Tampilan form laporan jadwal ............................................ 118
Gambar 4. 17 Membuat test (pengujian) unit (white box) ......................... 120
Gambar 4. 18 Menentukan test (pengujian) unit (white box) .................... 121
Gambar 4. 19 Melakukan test (pengujian) unit (white box) ...................... 122
Gambar 4. 20 Hasil test (pengujian) unit (white box) ................................ 122
Gambar 4. 21 Hasil test (pengujian) empat unit/modul unit (white box) .. 123
xv
DAFTAR TABEL
Tabel 2. 1 Tahapan pembuatan program java .............................................. 49
Tabel 3. 1 Tabel jenis persyaratan ............................................................... 63
Tabel 3. 2 Tabel jenis pembayaran .............................................................. 63
Tabel 3. 3 Tabel persyaratan ........................................................................ 63
Tabel 3. 4 Tabel pembayaran....................................................................... 64
Tabel 3. 5 Tabel detil pembayaran .............................................................. 64
Tabel 3. 6 Tabel calon siswa........................................................................ 64
Tabel 3. 7 Tabel siswa ................................................................................. 65
Tabel 3. 8 Tabel staf administrasi ................................................................ 65
Tabel 3. 9 Tabel guru ................................................................................... 65
Tabel 3. 10 Tabel jurusan ............................................................................ 66
Tabel 3. 11 Tabel kelas ................................................................................ 66
Tabel 3. 12 Tabel kelas siswa ...................................................................... 66
Tabel 3. 13 Tabel kelompok mata pelajaran ................................................ 66
Tabel 3. 14 Tabel mata pelajaran ................................................................. 67
Tabel 3. 15 Tabel jadwal ............................................................................. 67
Tabel 3. 16 Tabel jam .................................................................................. 67
Tabel 3. 17 Tabel nilai ................................................................................. 68
Tabel 4. 1 Pengujian fungsionalitas (functional testing) ........................... 119
xvi
DAFTAR SIMBOL
No. Simbol Nama Simbol Keterangan
1
Boundary Untuk menggambarkan
sistem atau aplikasi.
2
Actor Untuk menggambarkan
pengguna (user)
sistem/aplikasi
3
Use Case Untuk menggambarkan apa
yang dilakukan actor
terhadap sistem
4
Assosiation Garis lurus untuk
menunjukkan hubungan
actor dengan use case
5
Generalization Garis dengan ujung
berbentuk panah,
menunjukan use case sumber
(source) adalah penjabaran
(detil) dari use case yang
ditunjuk panah (destination)
6
Include Garis putus-putus dengan
ujung berbentuk panah,
menunjukan use case sumber
(source) akan selalu
dilakukan jika use case yang
ditunjuk panah (destination)
dilakukan
uc Use Case Model
Aplikasi
uc Use Ca...
Actor
uc Use Case Model
Use Case
uc Use Case Model
uc Use Case Model
uc Use Case Model
«include»
xvii
No. Simbol Nama Simbol Keterangan
7
Package Digunakan untuk
menggambarkan diagram
paket, yang berfungsi untuk
mengelompokkan use case
diagram atau class diagram
8
Trace Menggambarkan bahwa
sumber (source)
berhubungan dengan
sebagian/seluluh dalam
tujuan (destination)
9
Class Untuk menggambarkan class
yang memiliki attribute dan
method.
10
Import Untuk menggambarkan
bahwa package sumber
(source) diimport oleh
anggota dari package tujuan
(destination)
11
Initial Untuk menggambarkan awal
activity (aktivitas)
12
Final Untuk menggambarkan akhir
activity (aktivitas)
13
Activity Untuk menggambarkan
activity (aktivitas) yang
dilakukan
uc Use Case Model
Package
uc Use Case Model
Package
«trace»
class Class Model
Class
- attribute: int
+ method() : void
uc Use Case Model
Package Package
«import»
act A...
act A...
act Activ ity
Activ ity
xviii
No. Simbol Nama Simbol Keterangan
14
Decission Untuk menggambarkan
percabangan activity
(aktivitas)
15
Fork/Join Untuk menunjukkan proses
yang berjalan secara paralel
16
Boundary Untuk menggambarkan class
antarmuka (view) pada
sequence diagram
17
Control Untuk menggambarkan class
proses (controller) pada
sequence diagram
18
Entity Untuk menggambarkan class
entitas (model) pada
sequence diagram
act Activ ity
ac...
act Activ ity
sd Interaction
Boundary
sd Interaction
Control
sd Interaction
Entity
xix
DAFTAR LAMPIRAN
Lampiran 1 Formulir data pribadi calon siswa baru .................................. 129
Lampiran 2 Bidang keahlian bisnis dan manajemen SMK AVERUS ..... 131
Lampiran 3 Jadwal mengajar SMK Averus............................................... 132
Lampiran 4 Kwitansi SMK AVERUS ....................................................... 133
Lampiran 5 Kartu tanda bukti pembayaran SMK AVERUS..................... 134
Lampiran 6 Kartu hasil studi (KHS) SMK AVERUS ............................... 136
Lampiran 7 Kartu konsultasi mahasiswa ................................................... 138
1
BAB I
PENDAHULUAN
1.1 Latar Belakang
Pengolahan data administrasi dalam sebuah institusi pendidikan merupakan
kegiatan utama yang dilaksanakan secara periodik ataupun setiap saat, data-data
tersebut selalu berubah setiap bulan atau setiap tahun, penambahan siswa, maupun
perubahan kebijakan pemerintah menyebabkan data-data tersebut selalu berubah.
Sedangkan informasi yang dihasilkan dituntut untuk selalu aktual, sehingga
dibutuhkan suatu sistem yang dapat mengolah data-data administrasi secara
efisien dan efektif.
Saat ini media komputer telah menempati peranan penting dalam dunia
pendidikan (Sulindawaty & Calam, 2011). Sudah banyak sekolah-sekolah yang
memiliki komputer dan mengajarkan tentang teknologi informasi kepada murid-
muridnya. Tetapi teknologi informasi di sekolah masih sebatas ilmu yang
diajarkan di SMP, SMU, dan SMK sesuai kurikulum nasional (Kristanti & Redita,
2012). Belum banyak sekolah yang mengimplementasikan teknologi informasi
untuk menunjang pengolahan administrasinya. Komputerisasi administrasi
merupakan hal yang penting dalam lembaga pendidikan, karena dapat
mempermudah petugas administrasi dalam mengerjakan tugas-tugasnya (Antonio
& Safriadi, 2012).
SMK (Sekolah Menengah Kejuruan) AVERUS JAKARTA yang terletak
Pondok Pinang, Jakarta Selatan merupakan salah satu institusi pendidikan yang
belum menggunakan teknologi informasi secara efektif dan efisien dalam
pengolahan data administrasinya, karena data administrasinya sebagian dicatat
dan diolah secara manual, walaupun sudah ada yang dicatat dan diolah
menggunakan aplikasi komputer menggunakan Microsoft Excel. SMK AVERUS
JAKARTA belum menggunakan sistem terintegrasi dan terotomatisasi dalam
pengolahan administrasinya. Data-data administrasinya dicatat di dalam file-file
Microsoft Excel yang terpisah-pisah dalam folder sesuai kepentingan datanya
pada masing-masing komputer petugasnya.
2
Dengan melihat dan mengamati sistem yang sedang berjalan pada SMK
AVERUS JAKARTA, terlihat banyak duplikasi data, karena setiap petugas
memiliki master data sendiri-sendiri di dalam komputernya. Data-datanya tidak
mudah untuk dilakukan pembaharuan (update), karena jika dilakukan
pembaharuan (update) di salah satu komputer, maka data-data di komputer lain
tidak ikut diperbaharui. Sehingga harus dilakukan pembaharuan (update) data
pada setiap komputer. Dokumen-dokumennya tidak teroganisir dengan baik,
karena disimpan oleh masing-masing petugas dalam folder dan file sesuai
kepentingannya, jika ada petugas yang tidak hadir, maka petugas lain kesulitan
untuk menggantikan tugasnya karena tidak tahu lokasi penyimpanannya. Selain
itu juga kesulitan untuk mengevaluasi data pembayaran, data prestasi siswa, dan
lain-lain, karena data-datanya harus dikumpulkan, diperbaharui, dan diolah setiap
dilakukan evaluasi.
Membangun aplikasi administrasi sekolah merupakan salah satu solusi
pengolahan data secara komputerisasi, sehingga informasi yang dihasilkan efektif
dan efisien. Aplikasi yang baik harus didukung oleh model data yang baik, yaitu
model data yang fleksibel dan dapat disesuaikan dengan kebutuhan masa depan
(Widhyaestoeti, 2011), sehingga jika di masa depan ada kebutuhan baru, maka
dapat dengan mudah untuk ditambahkan atau diperbaharui.
Sesuai dengan permasalahan di atas, agar tidak terjadi duplikasi
data/dokumen, dan tidak harus memperbaharui data di semua komputer jika ada
perubahan, maka perlu dibuat aplikasi yang menggunakan satu basis data dan
dapat diakses oleh semua komputer. Arsitektur yang dapat digunakan adalah
client-server, arsitektur ini membagi proses/aktivitas menjadi dua, yaitu
proses/aktivitas yang berhubungan dengan interaksi dengan pengguna (user)
dilakukan oleh client, sedangkan proses yang berhubungan dengan pengolahan
basis data dilakukan di dalam server (Prasetyo, 2004). Dengan adanya pembagian
proses/aktivitas ini, maka beban pada sistem komunikasi (jaringan komputer)
dapat dikurangi, sehingga ketika jumlah client cukup banyak tidak terlalu
berpengaruh pada kinerja sistem (Alam, 2005). Client-server masih merupakan
arsitektur yang dominan dalam industri komputer karena memiliki keunggulan
dalam hal fleksibilitas, interoperabilitas, kinerja, ketahanan, distribusi dan
3
skalabilitas dibandingkan komputer stand-alone maupun mainframe (Vlugt &
Sambasivam, 2005).
Selain infrastruktur dan kinerjanya harus efektif dan efisien, pengembangan
aplikasinya pun harus efektif dan efisien juga. Arsitektur MVC (Model - View -
Controller) merupakan arsitektur terbaik untuk aplikasi desktop (Qureshi & Sabir,
2013). MVC merupakan arsitektur yang memisahkan dengan jelas antara data
(model) dengan user interface (view), dan telah terbukti sangat efektif (Widiyanto,
2010). Penggunaan MVC memungkinkan penyusunan source code (kode sumber)
aplikasi menjadi lebih rapi karena terjadi pemisahan dengan jelas antara business
logic (logika bisnis) dengan user interface (antarmuka pengguna), sehingga dapat
mengurangi kompleksitas source code (kode sumber), meningkatkan fleksibilitas
dan modularitas perangkat lunak ('Uyun & Ma'arif, 2010). Selain itu juga dapat
mempermudah perawatannya di masa yang akan datang (Utpatadevi, Sudana, &
Cahyawan, 2012). Dengan menggunakan MVC, alur aplikasi lebih mudah dibaca,
dan lebih mudah ditelusuri jika terjadi kesalahan (Martha, Harianto, & Asfi,
2010).
Berdasarkan hal-hal yang telah diuraikan di atas, maka penulis akan
membuat karya ilmiah dengan judul “IMPLEMENTASI ARSITEKTUR
CLIENT-SERVER DAN MVC (MODEL-VIEW-CONTROLLER) UNTUK
MEMBANGUN APLIKASI ADMINISTRASI SEKOLAH (STUDI KASUS:
SMK AVERUS JAKARTA)”.
1.2 Identifikasi Masalah
Berdasarkan latar belakang yang telah diuraikan sebelumnya, permasalahan-
permasalahan yang akan dibahas dan dicari solusinya antara lain:
a. Banyak terjadi duplikasi data, karena setiap dokumen yang disimpan
memiliki master data tersendiri sesuai kepentingannya.
b. Dokumen-dokumennya tidak teroganisir dengan baik karena disimpan
sesuai kepentingan datanya dan masing-masing staf yang bertanggung
jawab.
c. Pembuatan laporan-laporan dari data-data administrasi cenderung
lambat, karena belum terintegrasi dengan baik.
4
d. Aplikasi yang baik harus mudah disesuaikan dengan kebutuhan di masa
depan.
1.3 Tujuan
Tujuan dari pembuatan karya ilmiah ini antara lain:
a. Merancang dan membangun aplikasi administrasi sekolah dengan
arsitektur client-server untuk mengurangi duplikasi data.
b. Merancang dan membangun aplikasi administrasi sekolah untuk
memperbaiki pengorganisasian dokumen-dokumen di sekolah.
c. Merancang dan membangun aplikasi administrasi sekolah untuk
mempercepat pembuatan laporan-laporan yang diperlukan dari data-data
administrasi.
d. Mengimplementasikan arsitektur MVC (Model-View-Controller) agar
aplikasi lebih rapi dan mudah disesuaikan dengan kebutuhan di masa
depan.
1.4 Batasan
Agar pembahasan dalam pembuatan karya ilmiah ini tidak melebar dan
dapat mencapai tujuan yang telah ditetapkan, maka pada pembahasan karya ilmiah
ini dibatasi dengan hanya membahas administrasi kesiswaan mulai dari
penerimaan siswa, proses belajar mengajar, sampai kelulusan. Data-data yang
akan dimasukkan dalam pembahasan yaitu biodata siswa, data keuangan, dan data
nilai.
1.5 Manfaat
Adapun manfaat-manfaat yang dapat diperoleh dari karya ilmiah ini antara
lain:
a. Meningkatkan kinerja administrasi sekolah.
b. Mempermudah pengelolaan data-data siswa, pembayaran, dan nilai.
c. Mempermudah evaluasi terhadap proses belajar-mengajar.
5
1.6 Metodologi
Metode-metode yang digunakan dalam penyusunan karya ilmiah ini antara
lain:
A. Metode pengumpulan data
Pengumpulan data-data yang diperlukan dilakukan dengan beberapa cara,
yaitu:
a. Studi pustaka
Dilakukan dengan cara membaca referensi yang berkaitan dengan
masalah administrasi sekolah, arsitektur client-server, pemrograman
berorientasi objek, perancangan dan pembuatan basis data, dan
pengembangan aplikasi menggunakan MVC (Model-View-
Controller).
b. Studi lapangan (observasi)
Dilakukan dengan cara pengamatan langsung terhadap kegiatan yang
berhubungan dengan administrasi sekolah di SMK AVERUS
JAKARTA. Kegiatan administrasi yang diamati mulai dari
administrasi pendaftaran, administrasi pembayaran, administrasi
proses belajar-mengajar, sampai kelulusan.
c. Wawancara/Interview
Pengumpulan data dilakukan dengan cara bertatap muka langsung dan
melakukan tanya-jawab pada staf administrasi, guru, dan siswa.
B. Metode pengembangan aplikasi
Pengembangan aplikasi dibuat dengan arsitektur MVC (Model-View-
Controller) agar penyusunan aplikasi lebih rapi, dan mudah
dikembangkan sesuai kebutuhan di masa depan.
Sedangkan model yang digunakan dalam pengembangan aplikasi
menggunakan model spiral, karena model ini merupakan gabungan
antara model prototype dan model waterfall. Model spiral digunakan
untuk mengembangkan aplikasi berukuran besar dan untuk mengurangi
potensi kesalahan dalam pengembangan aplikasi. Sehingga model spiral
6
dirasa cocok dengan pengembangan aplikasi administrasi sekolah yang
akan dibuat.
1.7 Sistematika Penulisan
Dalam penyusunan karya ilmiah ini dilakukan pemisahan pembahasan
dalam bentuk bab dan subbab agar mudah dipelajari dan dipahami. Adapun
susunan penulisan karya ilmiah ini adalah sebagai berikut:
BAB I PENDAHULUAN
Pada bab pendahuluan berisi latar belakang, identifikasi masalah, tujuan
penelitian, batasan penelitian, manfaat penelitian, metodologi penelitian,
dan sistematika penulisan.
BAB II LANDASAN TEORI
Bab ini berisi tentang teori-teori yang mendukung pembuatan karya ilmiah
ini. Teori-teori yang dibahas mulai dari sistem administrasi sekolah, metode
pemrograman berorientasi objek, pembuatan rancangan aplikasi, arsitektur
client-server, arsitektur MVC, dan aplikasi-aplikasi pendukung perancangan
dan pembuatan aplikasi administrasi sekolah.
BAB III ANALISA DAN PERANCANGAN
Pada bab ini dilakukan analisa terhadap data/dokumen dan kegiatan/proses
yang ada dalam kegiatan administrasi sekolah di SMK AVERUS
JAKARTA. Kemudian dilakukan perancangan basis data dan aplikasi
administrasi sekolah yang akan dibuat.
BAB IV IMPLEMENTASI DAN PENGUJIAN
Berisi hasil implementasi dari perancangan aplikasi yang telah dibuat pada
bab III, dan berisi hasi pengujian terhadap aplikasi untuk mengetahui
kesiapan aplikasi untuk diimplementasi di SMK AVERUS JAKARTA.
BAB V PENUTUP
Pada bab penutup berisi kesimpulan dari hasil analisa dan pembahasan, serta
berisi saran-saran untuk perbaikan terhadap aplikasi yang telah dibuat agar
lebih baik.
7
BAB II
LANDASAN TEORI
2.1 Implementasi
Dalam Kamus Besar Bahasa Indonesia (KBBI), implementasi berarti
penerapan/pelaksanaan (Depdiknas, 2013). Implementasi dapat diartikan sebagai
suatu tindakan atau pelaksanaan dari sebuah rencana yang sudah disusun secara
matang dan terperinci. Implementasi biasanya dilakukan setelah perencanaaan
selesai dilakukan dan sudah dianggap final.
Jika dihubungkan dengan aplikasi, implementasi adalah penerapan dari
sebuah desain aplikasi yang telah dirancang dengan lengkap pada sebuah
pemrograman komputer. Dari implementasi ini akan dihasilkan sebuah aplikasi
komputer yang dapat berjalan sesuai rancangan yang telah dibuat.
2.2 Membangun Aplikasi
Aplikasi adalah penggunaan atau penerapan suatu konsep yang menjadi
pokok pembahasan. Aplikasi dapat diartikan juga sebagai program komputer yang
dibuat untuk menolong manusia dalam melaksanakan tugas tertentu. Aplikasi
software yang dirancang untuk penggunaan praktisi khusus, klasifikasi luas ini
dapat dibagi menjadi 2 (dua) yaitu:
a. Aplikasi software spesialis, program dengan dokumentasi tergabung
yang dirancang untuk menjalankan tugas tertentu.
b. Aplikasi paket, suatu program dengan dokumentasi tergabung yang
dirancang untuk jenis masalah tertentu.
Dalam Kamus Besar Bahasa Indonesia (KBBI), membangun berarti
mendirikan, mengadakan, atau memperbaiki (Depdiknas, 2013).
Jadi membangun aplikasi berarti membuat, mengadakan, atau memperbaiki
program komputer untuk membantu/mempermudah manusia dalam mengerjakan
tugas tertentu.
8
2.3 Administrasi Sekolah
2.3.1 Administrasi
Dalam Kamus Besar Bahasa Indonesia (KBBI), administrasi dapat diartikan
sebagai usaha dan kegiatan yang meliputi penetapan tujuan serta penetapan cara-
cara penyelenggaraan pembinaan organisasi, usaha dan kegiatan yang berkaitan
dengan penyelenggaraan kebijakan untuk mencapai tujuan, kegiatan yang
berkaitan dengan penyelenggaraan pemerintahan, atau kegiatan kantor dan tata
usaha (Depdiknas, 2013).
Administrasi adalah ilmu yang mempelajari proses kegiatan kerjasama
untuk mencapai tujuan yang telah ditentukan. Kegiatan kerjasama itu sendiri
merupakan gejala yang sifatnya universal dan memerlukan suatu proses
pergerakan yang disebut dengan manajemen. Dengan demikian, untuk mencapai
tujuannya administrasi perlu membentuk suatu manajemen dalam suatu organisasi
sebagai wadah, kerangka, atau struktur untuk menjalin suatu kerjasama yang baik.
Administrasi adalah keseluruhan proses kerjasama antara dua orang
manusia atau lebih yang didasarkan atas rasionalitas tertentu untuk mencapai
tujuan yang telah ditentukan sebelumnya (Antonio & Safriadi, 2012).
Secara etimologis administrasi berasal dari bahasa latin yang terdiri dari
kata ad yang berarti intensif dan ministraire yang berarti melayani. Literatur lain
menjelaskan bahwa administrasi merupakan terjemahan dari bahasa Inggris yaitu
administration yang bentuk infinitifnya adalah to administer. Atau administrasi
berasal dari bahasa Belanda, yaitu administratie yang meliputi kegiatan
pembukaan ringan, mencatat, menyurat, mengetik, agenda dan sebagainya yang
bersifat teknis ketatausahaan.
Berdasarkan uraian di atas dapat diambil kesimpulan bahwa administrasi
adalah kegiatan penyusunan dan pencatatan data secara sistematis dengan maksud
untuk menyediakan informasi serta memudahkan memperolehnya kembali secara
keseluruhan.
9
2.3.2 Administrasi Sekolah
Administrasi sekolah meliputi administrasi program pengajaran,
administrasi kesiswaan, administrasi kepegawaian, administrasi keuangan dan
administrasi perlengkapan atau barang.
A. Administrasi program pengajaran
Administrasi program pengajaran dilakukan dengan tujuan memudahkan
kepala sekolah dalam menyelenggarakan administrasi sekolah. Kegiatan
yang dilakukan meliputi menyusun jadwal pelajaran, program
pengajaran, pencatatan nilai dan pelaporan hasil belajar
B. Administrasi kesiswaan
Dalam adminstrasi kesiswaan selama satu tahun pelajaran dibagi dalam 3
tahap waktu dan dalam tiap tahapan waktu terdapat beberapa jenis
kegiatan, yaitu :
a. Awal tahun pelajaran
Penerimaan siswa baru
b. Selama tahun ajaran
- Penyusun data pribadi siswa
- Keadaan siswa awal tahun
- Kehadiran siswa
c. Akhir tahun pelajaran
- Pelaksanaaan ujian nasional
- Kenaikan kelas
C. Administrasi Kepegawaian
Administrasi kepegawaian menguraikan kegiatan yang berkaitan dengan
pengaturan kepegawaian, tugas dan tanggung jawab pengelolaan satuan
pendidikan dan peningkatan tata usaha kepegawaian di sekolah.
D. Administrasi Keuangan
Administrasi keuangan bertugas dan bertanggung jawab dalam
pengelolaan keuangan sekolah.
10
E. Administrasi Perlengkapan atau Barang
Administrasi perlengkapan atau barang memiliki tugas dalam
perencanaan, pengadaan, penyimpanan dan pemeliharaan semua
perlengkapan atau barang yang ada di sekolah.
Administrasi program pengajaran, kesiswaan, kepegawaian dibentuk ke
dalam satu divisi yaitu divisi tata usaha, sedangkan untuk administrasi keuangan
dibentuk secara khusus ke dalam divisi keuangan.
2.4 Arsitektur Client-Server
Arsitektur client-server merupakan arsitektur yang paling baik untuk
digunakan, sistem ini mampu menghasilkan aplikasi basis data yang tangguh
dalam hal sekuritas, serta mampu mengurangi kepadatan lalu-lintas jaringan
(Prasetyo, 2004). Dalam arsitektur client-server terdapat dua mesin yang
berfungsi sebagai server dan client.
Secara umum arsitektur client-server merupakan sebuah aplikasi
terdistribusi yang bertugas untuk mempartisi atau membagi pekerjaan antara
server (penyedia layanan) dan client. Client dan server sering juga beroperasi
menggunakan jaringan komputer pada hardware yang terpisah. Server adalah
sebuah mesin yang memiliki performa tinggi dan menjalankan satu atau lebih
program untuk memberikan data-data yang diminta oleh client (Prasetyo, 2004).
Sebuah client tidak mempunyai sumber daya apapun, namun meminta server
untuk menyediakan sumber daya yang diperlukan. Oleh karena itu client-lah yang
terlebih dahulu memulai sesi komunikasi dengan server yang menunggu request
(permintaan) dari client.
Arsitektur client-server merupakan model konektivitas pada jaringan yang
membedakan fungsi komputer sebagai client dan server. Pendek kata, arsitektur
client-server membagi beban kerja antara client dan server (Alam, 2005).
Arsitektur ini menempatkan sebuah komputer sebagai server, yang bertugas
memberikan pelayanan kepada terminal-terminal lainnya yang terhubung dalam
sistem jaringan atau yang disebut client. Server juga dapat bertugas untuk
11
memberikan layanan berbagi pakai berkas (file server), printer (printer server),
jalur komunikasi (communication server).
Pada arsitektur ini, client tidak dapat berfungsi sebagai server, tetapi server
dapat berfungsi menjadi client (server non-dedicated). Prinsip kerja pada
arsitektur ini sangat sederhana, di mana server akan menunggu permintaan dari
client, memproses dan memberikan hasil kepada client. Sedangkan client akan
mengirimkan permintaan ke server, menunggu proses dan melihat visualisasi hasil
prosesnya.
Server menurut bahasa inggris berasal dari kata serve yang berarti melayani,
dengan kata lain server bisa disebut juga dengan pelayan. Hal ini memang sesuai
tugas utama dari server adalah melayani, entah melayani permintaan atau
pengiriman.
Server dalam ilmu komputer adalah sebuah komputer (workstation) yang
difungsikan untuk melayani beberapa permintaan-permintaan tertentu. Server
dalam ilmu komputer juga terdapat beberapa jenis dan macamnya, semisal proxy
server yang bertugas sebagai pelayan proxy, SQL server yang bertugas sebagai
pelayan atau penyedia database, DHCP server yang melayani/menyediakan IP
address untuk client-nya, mail server yang melayani keluar masuk surat
elektronik (e-mail), web server yang melayani permintaan atau akses menuju web
yang berada pada server tersebut.
Server komputer berbeda dengan server manusia (pelayan, buruh). Dalam
kehidupan manusia, pelayan (baca: server) cenderung menempati posisi jabatan
yang paling rendah atau bisa dibilang sering tertindas oleh majikanya, ini
berbanding terbalik dengan server versi komputer yang menempati posisi jabatan
yang paling tinggi karena rata-rata komputer yang dijadikan sebagai server
memiliki spesifikasi hardware yang mumpuni daripada komputer client biasa,
karena memang tugasnya yang harus melayani client dengan jumlah yang tidak
sedikit.
Client-server adalah suatu hubungan antara pelayan dan yang dilayani,
seperti yang sudah saya jelaskan di atas bahwa server tugasnya adalah melayani
client, berikut ini ilustrasi hubungan client dengan server:
12
ServerNetwork
Client
Client
Client
Printer
Gambar 2. 1 Hubungan antara client dengan server
2.4.1 Kelebihan Client-Server
Aplikasi client-server memiliki beberapa kelebihan, antara lain:
a. Lebih aman
b. Semua data dapat di-backup pada satu lokasi sentral
c. Kecepatan akses lebih tinggi karena penyediaan fasilitas jaringan dan
pengelolaannya dilakukan secara khusus oleh satu komputer (server)
yang tidak dibebani dengan tugas lain sebagai workstation
2.4.2 Kekurangan Client-Server
Selain memiliki kelebihan, client-server juga memiliki kekurangan, yaitu:
a. Membutuhkan administrator yang handal
b. Pelaksanannya mahal
c. Jika server mati maka komputer client akan mati juga
2.5 Basis Data (Database)
Pengertian basis data (database) merupakan sekumpulan informasi yang
saling berkaitan pada suatu objek tertentu pada tujuan tertentu pula. Basis data
adalah susunan record data operasional lengkap dari suatu organisasi atau
perusahaan yang terorgansir dan disimpan secara terintegrasi dengan
13
menggunakan metode tertentu dalam komputer sehingga mampu memenuhi
informasi yang optimal yang dibutuhkan oleh para pengguna.
Basis data dalam bahasa inggris “database” adalah kumpulan informasi
yang disimpan di dalam komputer secara sistematik sehingga dapat diperiksa
menggunakan program komputer (software) untuk memperoleh informasi dari
basis data tersebut.
Perangkat lunak yang digunakan untuk mengelola dan memanggil query
basis data disebut sistem manajemen basis data (Database Management System
atau disingkat DBMS). Istilah “basis data” berawal dari ilmu komputer. Meskipun
kemudian artinya semakin luas, memasukkan hal-hal di luar bidang elektronika.
Catatan yang mirip dengan basis data sebenarnya sudah ada sebelum revolusi
industri yaitu dalam bentuk buku besar, kuitansi dan kumpulan data yang
berhubungan dengan bisnis. Konsep dasar dari basis data adalah kumpulan dari
catatan-catatan atau potongan dari pengetahuan.
Untuk membuat basis data dapat dilakukan melalui beberapa tahap
perancangan, yaitu:
a. Membuat ERD (Entity Relationship Diagram)
b. Membuat ERD (Entity Relationship Diagram) ke LRS (Logical Record
Structure)
c. Membuat LRS (Logical Record Structure)
d. Melakukan normalisasi
2.5.1 ERD (Entity Relationship Diagram)
Model E-R (Entity Relationship) adalah suatu model yang digunakan untuk
menggambarkan data dalam bentuk entitas, atribut, dan hubungan antarentitas
(Kadir, 2009). Karena model E-R dinyatakan dalam bentuk diagram, maka sering
disebut sebagai diagram E-R, atau dalam bahasa inggris disebut ERD (Entity
Relationship Diagram). ERD (Entity Relationship Diagram) merupakan jaringan
yang menggunakan susunan data yang disimpan pada sistem secara abstrak, tabel-
tabel ditunjukkan sebagai entitas atau relasi yang diimplementasikan melalui
kolom-kolom biasa dalam dua atau lebih tabel, menggunakan atribut yang dikenal
sebagai primary key dan foreign key (Widhyaestoeti, 2011). ERD hanya berfokus
14
pada data dan hubungan yang mengatur data tersebut (Kristanti & Redita, 2012).
ERD digunakan untuk memodelkan struktur data dan hubungan antardata, untuk
menggambarkannya digunakan beberapa notasi dan simbol. Pada dasarnya ada
tiga simbol yang digunakan, yaitu:
A. Entiti
Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat
dibedakan dari sesuatu yang lain. Simbol dari entiti ini biasanya
digambarkan dengan persegi panjang.
B. Atribut
Setiap entitas pasti mempunyai elemen yang disebut atribut yang
berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi
dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi
elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elips.
C. Hubungan/Relasi
Hubungan antara sejumlah entitas yang berasal dari himpunan entitas
yang berbeda. Relasi dapat digambarkan sebagai berikut :
Relasi yang terjadi di antara dua himpunan entitas (misalnya A dan B)
dalam satu basis data yaitu:
a. Satu ke satu (One to one)
Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A
berhubungan paling banyak dengan satu entitas pada himpunan entitas B.
b. Satu ke banyak (One to many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan
banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas
B dapat berhubungan dengan satu entitas pada himpunan entitas A.
c. Banyak ke banyak (Many to many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan
banyak entitas pada himpunan entitas B.
15
2.5.2 Transformasi ERD ke LRS
LRS (Logical Record Structure) adalah representasi dari struktur record-
record pada tabel-tabel yang terbentuk dari hasil antarhimpunan entitas.
Transformasi diagram ERD (Entity Relationship Diagram) ke LRS (Logical
Record Structure) merupakan suatu kegiatan untuk membentuk data-data dari
diagram hubungan entitas ke suatu LRS. Entitas dibedakan menjadi tipe entitas
kuat dan tipe entitas lemah (Kadir, 2009). Tipe entitas kuat adalah tipe entitas
yang keberadaannya tidak bergantung pada tipe entitas lain. Tipe entitas kuat
dinyatakan dengan tanda kotak.
Ada perlakuan berbeda dalam melakukan transformasi tipe entitas kuat ke
dalam relasi. Penentunya adalah jenis atribut, yaitu atribut sederhana, atribut
komposit, atribut bernilai banyak, ataupun atribut turunan, berikut ini adalah
penjelasannya:
a. Atribut sederhana
Suatu atribut sederhana ditransformasikan ke dalam relasi menjadi atribut
dalam relasi dengan cara sebagai berikut:
- Membentuk relasi dengan nama yang sama dengan nama dalam tipe
entitas.
- Meletakkan semua atribut dalam diagram E-R ke dalam relasi.
- Membentuk kunci primer relasi berupa atribut yang menjadi kunci
primer dalam tipe entitas.
b. Atribut komposit
Atribut komposit tidak perlu dimasukkan ke dalam relasi, karena bisa
diwakili oleh atribut sederhana yang menyusun atribut komposit tersebut.
Misalnya atribut alamat merupakan atribut komposit yang disusun oleh
atribut nama jalan, kota, dan kode pos, maka atribut alamat tidak perlu
dimasukkan, karena sudah terwakili oleh atribut nama jalan, kota, dan
kode pos.
c. Atribut bernilai banyak
Jika ada atribut bernilai banyak, maka dibuat relasi tambahan dengan
nama yang mencerminkan nama atribut tersebut. Kunci primer yang
digunakan berupa kunci primer dari tipe entitas ditambah dengan atribut
16
yang bernilai banyak. Misalnya entitas mahasiswa memiliki atribut hobi,
sedangkan atribut hobi dapat bernilai banyak, maka perlu dibuat relasi
hoby yang memiliki kunci primer NIM dan id_hobi.
d. Atribut turunan
Jika terdapat atribut turunan atau atribut gabungan, secara prinsip dapat
dilakukan transformasi menggunakan prinsip-prinsip yang telah dibahas.
Misalnya ada entitas karyawan memiliki atribut tanggal mulai bekerja,
maka tidak perlu ada atribut masa kerja, karena masa kerja dapat dihitung
berdasarkan atribut tanggal mulai bekerja.
2.5.3 Normalisasi
Desain basis data memengang peranan yang sangat penting dalam sistem
basis data, dan selayaknya dilakukan setelah adanya analisi sistem dan
permasalahan di tempat basis data diterapkan (Wahana Komputer, 2010). Desain
basis data perlu dilakukan secara cermat agar dihasilkan basis data yang efisien
dalam penggunaan ruang penyimpanan, cepat dalam pengaksesan, dan mudah
dalam manipulasi data. Salah satu cara yang dapat dilakukan dalam merancang
basis data seperti ini adalah dengan melakukan normalisasi.
Normalisasi adalah proses menata ulang basis data ke dalam bentuk standar
(normal) yang bertujuan untuk mencegah adanya anomali (Stephens R. , 2009).
Normalisasi juga didefinisikan sebagai suatu proses yang digunakan untuk
menentukan pengelompokan atribut-atribut dalam sebuah relasi sehingga
diperoleh relasi yang berstruktur baik, yaitu struktur yang mengandung
redundansi sesedikit mungkin, dan memungkinkan baris-baris dalam relasi
disisipkan, dimodifikasi, dan dihapus tanpa menimbulkan kesalahan atau
ketidakkonsistenan (Kadir, 2009). Proses normalisasi merupakan dasar untuk
pemodelan dan desain basis data relasional dengan tujuan untuk menghilangkan
redundansi data, menghindari data anomali yang dapat terjadi dalam basis data
unnormalized (basis data yang belum dinormalisasi), dan untuk menyederhanakan
penegakan kendala integritas (Stephens & Plew, 2001).
Berbeda dengan kebiasaan, biasanya teori ditemukan terlebih dahulu
sebelum diterapkan dalam praktik. Teori normalisasi dibangun atau dibentuk
17
menurut konsep level normalisasi. Level normalisasi atau sering disebut sebagai
bentuk normal suatu relasi, dijelaskan berdasarkan kriteria tertentu pada bentuk
normal. Setidaknya terdapat dua pendekatan untuk normalisasi, yaitu bekerja dari
Entity Relationship Diagram (ERD), atau menggunakan konsep-konsep teoritis di
balik desain yang baik untuk membuat relasi (Harrington, 2009).
Bentuk normal yang dikenal hingga saat ini meliputi bentuk 1NF (First
Normalized Form), 2NF (Second Normalized Form), 3NF (Third Normalized
Form), BCNF (Boyce-Codd Normalized Form/BCNF), 4NF (Forth Normalized
Form), 5NF (Fifth Normalized Form), dan DKNF (Domain Key Normalized
Form). Secara berturut-turut masing-masing level normal tersebut akan dibahas
dari bentuk tidak normal, berikut ini penjelasan dari masing-masing level:
A. Relasi bentuk tidak normal (Un-Normalized Form/UNF)
Relasi bentuk tidak normal adalah relasi-relasi yang dirancang tanpa
mengindahkan batasan dalam definisi basis data dan karakteristik
RDBMS (Relational Database Management System). Pada bentuk ini
semua data pada tiap entity (diambil atributnya) dan ditampung dalam
tabel besar, sehingga masih ada kemungkinan terjadi redudansi atau
kosong (Wahana Komputer, 2010). Bentuk ini harus dihindari dalam
perancangan relasi dalam basis data. Relasi UNF mempunyai kriteria
sebagai berikut:
a. Jika relasi mempunyai bentuk nonflat file (dapat terjadi akibat data
disimpan sesuai dengan kedatangannya, tidak memiliki struktur
tertentu, terjadi duplikasi atau tidak lengkap)
b. Jika relasi memuat set atribut berulang (nonsingle value)
c. Jika relasi memuat atribut nonatomic value
B. Relasi bentuk normal pertama (First Normalized Form/1NF)
Suatu relasi dapat disebut dengan 1NF apabila memenuhi kriteria sebagai
berikut:
a. Jika seluruh atribut dalam relasi bernilai atomic (atomic value)
b. Jika seluruh atribut dalam relasi bernilai tunggal (single value)
c. Jika relasi tidak memuat set atribut berulang
18
d. Jika semua record mempunyai sejumlah atribut yang sama
Dengan kata lain bentuk normal pertama adalah sebuah model data yang
setiap atribut yang dimilikinya memiliki satu dan hanya satu nilai.
Apabila ada atribut yang memiliki nilai lebih dari satu, atribut tersebut
adalah kandidat untuk menjadi entitas tersendiri.
Permasalahan dalam 1NF adalah sebagai berikut:
a. Tidak dapat menyisipkan informasi persial
b. Terhapusnya informasi ketika menghapus sebuah record
c. Pembaharuan atribut nonkunci mengkibatkan sejumlah record harus
diperbaharui
Mengubah relasi UNF menjadi 1NF dapat dilakukan dengan cara
sebagai berikut:
a. Melengkapi nila-nilai dalam atribut
b. Mengubah struktur relasi
C. Bentuk normal kedua (Second Normalized Form/2NF)
Relasi disebut 2NF jika memenuhi kriteria sebagai berikut:
a. Jika memenuhi kriteria 1NF
b. Jika semua atribut nonkunci ketergantungan fungsional (functionally
defedency/FD) pada PK (Primary Key)
Sebuah model data memenuhi bentuk normal kedua apabila memenuhi
bentuk normal pertama dan setiap atribut non-identifier sebuah entitas
bergantung sepenuhnya hanya pada semua identifier entitas tersebut.
Pemasalahan dalam 2NF adalah sebagai berikut:
a. Kerangkapan data.
b. Pembaharuan yang tidak benar dapat menimbulkan ketidak-
konsistenan data.
c. Proses pembaharuan data tidak efisien.
d. Permasalahan pada saat penyisipan, penghapusan, dan pembaharuan.
19
Mengubah relasi 1NF menjadi bentuk 2NF dapat dilakukan dengan
mengubah struktur relasi dengan cara:
a. Identifikasi FD relasi 1NF (jika perlu gambarkan diagram
ketergantungan datanya)
b. Berdasarkan informasi tersebut, dekomposisi relasi 1NF menjadi
relasi-relasi baru sesuai FD-nya. Jika menggunakan diagram maka
simpul-simpul yang berada pada puncak diagram ketergantungan data
bertindak sebagai PK pada relasi baru.
D. Bentuk normal ketika (Third Normalized Form/3NF)
Suatu relasi disebut sebagai 3NF jika memenuhi kriteria sebagai berikut:
a. Jika memenuhi kriteria 2NF
b. Jika setiap atribut nonkunci tidak bergantung transitif (non transitive
dependency) terhadap PK.
Sebuah model data memenuhi bentuk normal ketiga apabila memenuhi
bentuk normal kedua dan tidak ada satupun atribut non-identifying
(bukan pengidentifikasi unik) yang bergantung pada atribut non-
identifying lain. Apabila ada, pisahkan salah satu atribut tersebut menjadi
entitas baru, dan atribut yang bergantung padanya menjadi atribut entitas
baru tersebut.
Mengubah relasi 2NF menjasi bentuk 3NF dapat dilakukan dengan
mengubah struktur relasi dengan cara sebagai berikut:
a. Identifikasi kebergantungan transitif pada relasi 2NF (jika perlu
gambarkan diagram ketergantungan datanya)
b. Berdasarkan informasi tersebut, dekomposisi relasi 2NF menjadi
relasi-relasi baru sesuai kebergantungan transitifnya. Jika
menggunakan diagram maka simpul-simpul yang berada pada puncak
diagram ketergantungan data bertindak sebagai PK pada relasi baru.
20
Misalkan, terhadap relasi R dengan sifat sebagai berikut:
a. R=(A, B, C) dengan PK=A
b. FD: R.B→R.C
Maka relasi R perlu didekomposisi menjasi relasi-relasi R1 dan R2,
yaitu:
a. R1=(B, C)
b. R2=(A, B), FK: B references R1
E. Bentuk normal Boyce-Codd (Boyce-Codd Normalized Form/BCNF)
Bentuk normal BCNF dikemukakan oleh R. F. Boyce dan E. F. Codd.
Suatu relasi disebut dengan BCNF jika memenuhi kriteria sebagai
berikut:
a. Jika memenuhi kriteria 3NF
b. Jika semua atribut penentu (determinan) merupakan CK (Candidate
Key)
F. Bentuk normal keempat (Forth Normalized Form/4NF)
Relasi disebut sebagai 4NF jika memenuhi kriteria senagai berikut:
a. Jika memenuhi kriteria BCNF
b. Jika setiap atribut di dalamnya tidak mengalami ketergantungan pada
banyak nilai. Atau dengan kalimat lain, bahwa semua atribut yang
mengalami ketergantungan pada banyak nilai adalah bergantung
secara fungsional (functionally dependency).
G. Bentuk normal kelima (Fifth Normalized Form/5NF)
Suatu relasi memenuhi kriteria 5NF kerelasian antardata dalam relasi
tersebut tidak dapat direkonstruksi dari struktur relasi yang sederhana.
Relasi 5NF memiliki kriteria sebagai berikut:
a. Kerelasian antardata dalam relasi tersebut tidak dapat direkonstruksi
dari struktur relasi yang memuat atribut yang lebih sedikit.
21
b. Bentuk normal 5NF terpenuhi jika tidak dapat memiliki sebuah
lossless decomposition menjadi tabel-tabel yang lebih kecil.
c. Jika 4 bentuk normal sebelumnya dibentuk berdasarkan functional
dependency, 5NF dibentuk berdasarkan konsep join dependence,
yakni apabila sebuah tabel telah didekomposisi menjadi tabel-tabel
lebih kecil, harus bisa digabungkan lagi (join) untuk membentuk tabel
semula
H. Bentuk normal kunci domain (Domain Key Normalized Form/DKNF)
Suatu relasi disebut sebagai DKNF jika setiap batasan dapat disimpulkan
secara sederhana dengan mengetahui sekumpulan nama atribut dan
domainnya selama menggunakan sekumpulan atribut pada kuncinya.
Bentuk DKNF ini dikemukakan oleh R. Fagin pada 1981 dan bersifat
sangat spesifik, artinya tidak semua relasi dapat mencapai level ini.
2.6 Pengembangan Aplikasi
Pengembangan aplikasi (software) adalah usaha/proses sistematik, disiplin,
pendekatan kuantitatif untuk pengembangan, operasi dan pemeliharaan dari
aplikasi (software). Dengan kata lain, pengembangan aplikasi (software)
merupakan sebuah metodologi yang membahas semua aspek produksi aplikasi
(software), mulai dari tahap awal spesifikasi aplikasi (software) hingga pada tahap
pemeliharaan aplikasi (software) setelah digunakan dengan tujuan untuk membuat
aplikasi (software) yang tepat dengan metode yang tepat.
Untuk meningkatkan fungsionalitas dan efisiensi aplikasi, dan juga
kemudahan dan efisiensi dalam pengembangan aplikasi dapat menggunakan
teknik rekayasa perangkat lunak (Simarmata, 2010). Rekayasa perangkat lunak
adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat
lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembangan
perangkat lunak, dan sebagainya.
22
2.6.1 Siklus Hidup Pengembangan Aplikasi
Pengembangan aplikasi (software) merupakan tugas kompleks yang
membutuhkan banyak sumber daya dan dapat memakan waktu berbulan-bulan
bahkan bertahun-tahun untuk menyelesaikannya. Proses pengembangan aplikasi
(software) melewati beberapa tahapan, dari mulai aplikasi (software) itu
direncanakan, diterapkan, dioperasikan, sampai pemeliharaan. Bila operasi
aplikasi (software) yang sudah dikembangkan masih timbul permasalahan-
permasalahan kritis serta tidak dapat diatasi dalam tahap pemeliharaan aplikasi
(software), maka perlu dikembangkan kembali suatu aplikasi (software) untuk
mengatasinya dan proses ini kembali ke tahap yang pertama, yaitu tahap
perencanaan sistem.
Siklus hidup pengembangan aplikasi/sistem (Systems Development Life
Cycle disingkat SDLC) adalah proses memahami bagaimana sistem informasi
dapat mendukung kebutuhan bisnis, merancang sistem, membangun, dan
memberikan ke pengguna (Dennis, Wixom, & Roth, 2009). Siklus hidup
pengembangan aplikasi (software) merupakan pendekatan melalui beberapa tahap
untuk menganalisis dan merancang sistem yang di mana sistem tersebut telah
dikembangkan dengan sangat baik melalui penggunaan siklus kegiatan
penganalisis dan pemakai secara spesifik, siklus itu antara lain:
a. Pengumpulan data (data gathering)
Jika sudah ada sistem yang berjalan sebelumnya maka perlu dilakukan
pengumpulan data dan informasi yang dihasilkan dari sistem yang ada.
Pengumpulan laporan (report), cetakan (print-out), dan sebagainya, baik
yang sudah ada maupun yang diharapkan untuk ada pada sistem yang
baru. Interview dan kuesioner terhadap orang-orang yang terlibat dalam
sistem juga mungkin perlu dilakukan. Apabila sistem yang akan
dikembangkan benar-benar baru (belum ada sistem informasi
sebelumnya) maka pada tahapan ini pengembang bisa lebih menekankan
kepada studi kelayakan dan definisi sistem.
b. Analisa sistem
Jika tahapan pengumpulan data dilakukan dengan melibatkan klien atau
pengguna sistem informasi, maka mulai dari tahapan analisa lebih
23
banyak dilakukan oleh pihak pengembang sendiri. Analisa terhadap
sistem yang sedang berjalan dan sistem yang akan dikembangkan.
Mendefinisikan objek-objek yang terlibat dalam sistem dan batasan
sistem.
c. Perancangan sistem (design)
Merancang alir kerja (workflow) dari sistem dalam bentuk diagram alir
(flowchart) atau Data Flow Diagram (DFD). Merancang basis data
(database) dalam bentuk Entity Relationship Diagram (ERD) bisa juga
sekalian membuat basis data secara fisik. Merancang input dan ouput,
antarmuka (interface), dan menentukan form-form dari setiap modul
yang ada. Merancang arsitektur aplikasi dan jika diperlukan menentukan
juga kerangka kerja (framework) aplikasi. Pada tahapan ini atau
sebelumnya sudah ditentukan teknologi dan tools (peralatan) yang akan
digunakan baik selama tahap pengembangan (development) maupun pada
saat implementasi (deployment).
d. Penulisan kode program (coding)
Programming (desktop application) atau Scripting (web-based
application) hanyalah salah satu tahapan dari siklus hidup pengembangan
sistem. Tahapan ini dilakukan oleh satu atau lebih programmer. Jika
tahapan analisa dan perancangan sistem telah dilakukan dengan baik,
maka porsi tahapan coding (pengkodean) tidaklah besar.
e. Testing
Biasanya tahapan ini dilakukan oleh Quality Assurance (QA) dari pihak
pengembang untuk memastikan bahwa software yang dibangun telah
berjalan sesuai dengan yang diharapkan. Salah satu metodenya bisa
dengan meng-input sejumlah data pada sistem baru dan membandingkan
hasilnya dengan sistem lama. Apabila diperlukan maka tahapan ini bisa
dibagi menjadi dua yaitu testing oleh pihak pengembang (alpha testing)
dan testing oleh pihak pengguna (beta testing).
f. Instalasi
Pada pengembangan aplikasi client-server, umumnya terdapat server
untuk development, testing, dan production. Server development berada
24
di tempat pengembang dan dipergunakan selama pengembangan dan bisa
juga setelahnya untuk perbaikan aplikasi secara terus menerus
(continuous improvements). Server testing berada di tempat pengembang
dan bisa juga di tempat pengguna apabila diperlukan beta testing. Setelah
aplikasi dirasa siap untuk dipergunakan maka digunakanlah server
production yang berada di tempat pengguna. Pada prakteknya di tempat
pengembang juga bisa terdapat server production yaitu server yang
memiliki spesifikasi hardware dan software yang sama dengan server di
tempat pengguna. Hal ini dimaksudkan agar apabila ditemukan error
atau bug pada aplikasi di tempat pengguna maka pengembang dapat
mudah mencari penyebabnya pada server production mereka.
g. Pelatihan
Pihak pengembang memberikan training bagi para pengguna program
aplikasi sistem informasi ini. Apabila sebelumnya tidak dilakukan beta
testing maka pada tahapan ini juga bisa dilangsungkan User Acceptance
Test (UAT).
h. Pemeliharaan
Maintenance bertujuan untuk memastikan bahwa sistem yang digunakan
oleh pihak pengguna benar-benar telah stabil dan terbebas dari error dan
bug. Pemeliharaan ini biasanya berkaitan dengan masa garansi yang
diberikan oleh pihak pengembang sesuai dengan perjanjian dengan pihak
pengguna. Lamanya waktu pemeliharaan sangat bervariasi. Namun pada
umumnya sistem informasi yang kompleks membutuhkan masa
pemeliharaan dari enam bulan hingga seumur hidup program aplikasi.
2.6.2 Model Pengembangan Aplikasi
System Development Life Cycle (SDLC) memberikan landasan pada proses
yang digunakan untuk mengembangkan sistem informasi (Dennis, Wixom, &
Roth, 2009). Ada beberapa model pengembangan aplikasi/sistem yang dapat
digunakan, berikut ini beberapa model pengembangan aplikasi (software):
25
A. Model sekuensial linier (waterfall)
Model sekuensial linier sering disebut model air terjun (waterfall)
merupakan paradigma rekayasa perangkat lunak yang paling tua dan
paling banyak dipakai. Model ini memungkinkan pemecahan misi
pengembangan yang rumit menjadi beberapa langkah logis (Simarmata,
2010), yaitu dengan mengusulkan sebuah pendekatan perkembangan
perangkat lunak yang sistematik dan sekunsial yang dimulai pada tingkat
dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan
pemeliharaan.
Model sekunsial linier mengikuti aktivitas-aktivitas berikut ini:
a. Rekayasa dan pemodelan sistem/informasi
Karena perangkat lunak merupakan bagian dari suatu sistem maka
langkah pertama dimulai dengan membangun syarat semua elemen
sistem dan mengalokasikan ke perangkat lunak dengan
memeperhatiakn hubungannya dengan manusia, perangkat keras dan
basis data.
b. Analisis kebutuhan perangkat lunak
Proses menganalisis dan pengumpulan kebutuhan sistem yang sesuai
dengan domain informasi tingkah laku, unjuk kerja, dan antar muka
(interface) yang diperlukan. Kebutuhan-kebutuhan tersebut
didokumentasikan dan dilihat lagi dengan pelanggan.
c. Desain
Proses desain akan menerjemahkan syarat kebutuhan ke sebuah
perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat
coding. Proses ini berfokus pada struktur data, arsitektur perangkat
lunak, representasi interface, dan detil algoritma prosedural.
d. Pengkodeaan (coding)
Pengkodean merupakan proses menerjemahkan desain ke dalam suatu
bahasa yang bisa dimengerti oleh komputer.
e. Pengujian
Proses pengujian dilakukan pada logika internal untuk memastikan
semua pernyataan sudah diuji. Pengujian eksternal fungsional untuk
26
menemukan kesalahan-kesalahan dan memastikan bahwa input akan
memberikan hasil yang aktual sesuai yang dibutuhkan.
f. Pemeliharaan
Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan
mengalami perubahan. Perubahan tersebut bisa karena mengalami
kesalahan karena perangkat lunak harus menyesuaikan dengan
lingkungan (periperal atau sistem operasi baru) baru, atau karena
pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.
Sebelum menggunakan model sekuensial linier (waterfall), dapat
mempertimbangkan kelebihan dan kekurangannya.
Kelebihan dari model sekuensial linier (waterfall) adalah:
a. Mudah aplikasikan.
b. Memberikan template tentang metode analisis, desain, pengkodean,
pengujian, dan pemeliharaan.
Kekurangan dari model sekuensial linier (waterfall) adalah:
a. Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan
model karena model ini bisa melakukan itersi tidak langsung . Hal ini
berakibat ada perubahan yang diragukan pada saat proyek berjalan.
b. Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga
sulit untuk megakomodasi ketidakpastian pada saat awal proyek.
c. Pelanggan harus bersikap sabar karena harus menunggu sampai akhir
proyek dilalui. Sebuah kesalahan jika tidak diketahui dari awal akan
menjadi masalah besar karena harus mengulang dari awal.
d. Pengembang sering malakukan penundaan yang tidak perlu karena
anggota tim proyek harus menunggu tim lain untuk melengkapi tugas
karena memiliki ketergantungan hal ini menyebabkan penggunaan
waktu tidak efesien.
27
B. Prototipe (Prototype)
Prototyping merupakan salah satu metode pengembangan perangat lunak
yang banyak digunakan. Dengan metode prototyping ini pengembang
dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem.
Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa
yang dikehendakinya tanpa menyebutkan secara detil output apa saja
yang dibutuhkan, pemrosesan dalam aplikasi, dan data-data apa saja yang
dibutuhkan. Sebaliknya di sisi pengembang kurang memperhatikan
efesiensi algoritma, kemampuan sistem operasi dan interface yang
menghubungkan manusia dengan komputer.
Untuk mengatasi ketidakserasian antara pelanggan dan pengembang,
maka dibutuhkan kerjasama yanga baik di antara keduanya sehingga
pengembang akan mengetahui dengan benar apa yang diinginkan
pelanggan dengan tidak mengesampingkan segi-segi teknis, dan
pelanggan akan mengetahui proses-proses dalam menyelesaikan sistem
yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai
dengan jadwal waktu penyelesaian yang telah ditentukan.
Kunci agar model prototype ini berhasil dengan baik adalah dengan
mendefinisikan aturan-aturannya pada saat awal, yaitu pelanggan dan
pengembang harus setuju bahwa prototype dibangun untuk
mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian atau
seluruhnya, dan perangkat lunak aktual direkayasa dengan kualitas dan
implementasi yang sudah ditentukan.
Tahapan-tahapan dalam model prototyping adalah sebagai berikut:
a. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format
seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan
garis besar sistem yang akan dibuat.
b. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara
yang berfokus pada penyajian kepada pelanggan (misalnya dengan
membuat input dan format output).
28
c. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang
dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai
maka dilanjutkan langkah “d”. Jika tidak prototyping direvisi dengan
mengulangi langkah “a”, “b” , dan “c”.
d. Mengkodekan sistem
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke
dalam bahasa pemrograman yang sesuai.
e. Menguji sistem
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai,
harus diuji dahulu sebelum digunakan. Pengujian ini dilakukan
dengan White Box, Black Box, Basis Path, pengujian arsitektur dan
lain-lain.
f. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai
dengan yang diharapkan. Jika ya, langkah “g” dilakukan; jika tidak,
ulangi langkah ”d” dan “e”.
g. Menggunakan sistem
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk
digunakan.
Keunggulan model prototyping adalah:
a. Adanya komunikasi yang baik antara pengembang dan pelanggan.
b. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan
pelanggan.
c. Pelanggan berperan aktif dalam pengembangan sistem.
d. Lebih menghemat waktu dalam pengembangan sistem.
e. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang
diharapkannya.
29
Kelemahan prototyping adalah:
a. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat
lunak yang ada belum mencantumkan kualitas perangkat lunak secara
keseluruhan dan juga belum memikirkan kemampuan pemeliharaan
untuk jangka waktu lama.
b. Pengembang biasanya ingin cepat menyelesaikan proyek, sehingga
menggunakan algoritma dan bahasa pemrograman yang sederhana
untuk membuat prototyping lebih cepat selesai tanpa memikirkan
lebih lanjut bahwa program tersebut hanya merupakan cetak biru
sistem.
c. Hubungan pelanggan dengan komputer yang disediakan mungkin
tidak mencerminkan teknik perancangan yang baik.
Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri
sebagai berikut:
a. Resiko tinggi, yaitu untuk masalah-masalah yang tidak terstruktur
dengan baik, ada perubahan yang besar dari waktu ke waktu, dan
adanya persyaratan data yang tidak menentu.
b. Interaksi pemakai penting. Sistem harus menyediakan dialog online
antara pelanggan dan komputer.
c. Perlunya penyelesaian yang cepat.
d. Perilaku pemakai yang sulit ditebak.
e. Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian
masalah dan penggunaan perangkat keras yang mutakhir.
f. Perkiraan tahap penggunaan sistem yang pendek.
C. Incremental
Pembuatan sofware dengan model incremental merupakan proses yang
terpecah menjadi beberapa bagian. Model ini mengandalkan prioritas dan
sistematika, jadi software yang paling penting dan yang paling
berpengaruh pada software lain yang harus dikerjakan terlebih dahulu.
Diumpakan seperti menjahit baju, pertama-tama yang harus dilakukan
30
adalah menggambar pola, menggunting kain, dan menjahitnya.
Menggunting kain tidak dapat dilakukan sebelum menggambar pola, dan
baju tak dapat dijahit sebelum kainnya digunting. Seperti itulah ilustrasi
model incremental.
Kelebihan model incremental:
a. Personil bekerja optimal.
b. Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian
yang telah selesai dibangun.
c. Mengurangi trauma karena perubahan sistem. Klien dibiasakan
perlahan-lahan menggunakan produknya bagian per bagian.
Kekurangan model incremental:
a. Ada kemungkinan tiap bagian tidak dapat diintegrasikan.
b. Diperlukan kemampuan untuk selalu melakukan perubahan tanpa
menurunkan kualitas.
c. Memungkinkan penambahan staf.
D. Spiral
Merupakan gabungan model prototyping dan waterfall. Proses
pembuatannya mulai dari customer communication, planning, risk
analysis, engineering, construction and release, customer evaluation.
Proses ini akan terus berulang demi pemenuhan kebutuhan pelanggan,
walaupun perangkat lunak telah selesai.
Kelebihan model spiral:
a. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala
besar
b. Dapat digunakan dalam waktu sangat lama karena perubahan terus
dilakukan
c. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga
mengurangi resiko sebelum menjadi permasalahan yang serius
31
Kelemahan model spiral:
a. Sulit untuk mengontrol perubahan yang ingin dilakukan karena jangka
panjang
b. Sulit meyakinkan pelanggan mengenai pendekatan evolusioner
c. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi
masalah yangserius jika resiko mayor tidak ditemukan dan diatur.
d. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian
yang absolut.
2.7 Pemrograman Berorientasi Objek
Pemrograman berorientasi objek merupakan paradigma baru dalam rekayasa
software yang didasarkan pada objek dan kelas. Diakui para ahli bahwa
pemrograman berorientasi objek merupakan metodologi terbaik yang ada saat ini
dalam rekayasa software. Pemrograman berorientasi objek menggantikan
pemrograman terstruktur karena mempunyai banyak keunggulan dalam
menangani proyek yang luar biasa kompleks (Hariyanto, 2007). Pemrograman
berorientasi objek memandang software bagian per bagian, dan menggambarkan
satu bagian tersebut dalam satu objek. Satu objek dalam sebuah model merupakan
suatu fokus selama dalam proses analisis, perancangan dan implementasi dengan
menekankan pada state, perilaku (behavior) dan interaksi objek dalam model
tersebut.
Pemrograman berorientasi objek merupakan suatu konsep yang banyak
digunakan oleh pengembang software, karena menawarkan kemudahan dalam
desain, pengembangan, dan perawatan, sehingga merupakan pendekatan yang
efektif untuk membangun perangkat lunak yang fleksibel. Teknologi pemodelan
dan pemrograman berorientasi objek memudahkan dalam pengembangan
software, baik pengubahan, menambah, dan memperbaiki arsitektur software
(Sumarta, Siswoyo, & Juhana, 2004).
Pemrograman berorientasi objek adalah sebuah konsep pemrograman untuk
membuat kode program yang lebih terstruktur, terkelompok, berdasarkan objek-
objek yang terlibat sehingga bagian-bagiannya dapat digunakan untuk pembuatan
aplikasi lain. Pemrograman berorientasi objek membagi-bagi kode program
32
aplikasi menjadi kumpulan bungkusan benda/objek dipandang dari sudut pandang
aplikasi komputer dan proses yang dilakukan dalam aplikasi.
2.7.1 Prinsip-prinsip Pemrograman Berorientasi Objek
Ada tujuh prinsip pengembangan berorientasi objek yang terdiri dari empat
prinsip utama, yaitu abstraksi (abstraction), enkapsulasi (encapsulation),
modularitas (modularity), hirarki (hierarchy)], dan tiga prinsip tambahan, yaitu
mengetik (typing), konkurensi (concurrency), dan ketekunan (persistence)
(Booch, 1994). Jika ada prinsip utama yang tidak terpenuhi, maka tidak dapat
dianggap berorientasi objek. Sedangkan prinsip tambahan berguna untuk
kemudahan, tetapi tetap dapat dianggap berorientasi objek walaupun tidak ada.
Berikut ini adalah penjelasan dari empat prinsip utama dari pemrograman
berorientasi objek:
a. Abstraksi
Memfokuskan perhatian pada karakteristik objek yang paling penting dan
paling dominan yang bisa digunakan untuk membedakan objek tersebut
dari objek lainnya. Dengan abstraksi ini pengembang bisa menerapkan
konsep KIS (Keep It Simple) pada objek di dunia nyata yang memiliki
tingkat kerumitan yang tinggi.
b. Enkapsulasi
Menyembunyikan banyak hal yang terdapat dalam objek yang tidak perlu
diketahui oleh objek lain. Dalam praktek pemrograman enkapsulasi
diwujudkan dengan membuat suatu kelas interface yang akan dipanggil
oleh objek lain, sementara di dalam objek yang dipanggil terdapat kelas
lain yang mengimplementasikan apa yang terdapat dalam kelas interface.
Objek lain hanya tahu dia perlu memanggil kelas interface tanpa perlu
tahu proses apa saja yang dilakukan di dalam kelas implementasinya, dan
untuk menuntaskan proses tersebut perlu berhubungan dengan objek
mana saja. Dengan demikian bila terjadi proses perubahan pada proses
implementasi maka objek pemanggil tidak akan terpengaruhi secara
langsung.
33
c. Modularitas
Membagi sistem yang rumit menjadi bagian-bagian yang lebih kecil yang
bisa mempermudah pengembang memahami dan mengelola objek
tersebut. Contohnya adalah sistem akademis yang bisa dibagi menjadi
kemahasiswaan, daftar mata kuliah, pembayaran uang kuliah, dan lain-
lain.
d. Hirarki
Hirarki berhubungan dengan abstraksi dan modularitas, yaitu pembagian
berdasarkan urutan dan pengelompokan tertentu. Misalnya untuk
menentukan objek mana yang berada pada kelompok yang sama, objek
mana yang merupakan komponen dari objek yang memiliki hirarki lebih
tinggi. Semakin rendah hirarki objek berarti semakin jauh abstraksi
dilakukan terhadap suatu objek.
Keempat prinsip dasar ini merupakan hal yang mendasari teknologi objek
yang perlu ditanamkan dalam cara berpikir pengembang berorientasi objek.
2.7.2 Bahasa Pemrograman Berorientasi Objek
Sebuah bahasa berorientasi objek bukan hanya yang berbasis obyek, tetapi
juga menyediakan dukungan untuk pewarisan dan polimorfisme (Booch, 1994).
Jadi, sebuah bahasa pemrograman dinyatakan mendukung pemrograman
berorientasi objek jika bahasa itu mendukung syarat-syarat pemrograman
berorientasi objek sebagai berikut:
a. Enkapsulasi (encapsulation)
Mampu membungkus atribut-atribut dan metode-metode dalam sebuah
kelas, dan dapat mencegah pengaksesan langsung terhadap atribut-atribut
dan metode-metode yang diinginkan di dalam sebuah kelas.
b. Pewarisan (inheritance)
Memungkinkan adanya pendefinisian kelas baru yang memiliki sifat-sifat
keturunan dari kelas lain.
34
c. Polimorfisme (polymorphism)
Memungkinkan pembuatan pengaksesan metode-metode dengan nama
yang sama namun berbeda parameter masukan atau berbeda kelas.
2.7.3 Desain Pemrograman Berorientasi Objek
UML (Unified Modelling Language) adalah salah satu alat bantu yang
sangat handal di dunia pengembangan sistem berorientasi objek karena
menyediakan bahasa pemodelan visual yang memungkinkan pengembang
membuat cetak biru atas visi mereka dalam bentuk baku, mudah dimengerti, serta
dilengkapi mekanisme yang efektif untuk berbagi (sharing) dan
mengkomunikasikan rancangan dengan pihak lain (Munawar, 2005).
Sejak tahun 1997, UML telah dijadikan sebagai standar pengembangan
berorientasi objek (Dennis, Wixom, & Roth, 2009), juga sebagai standar bahasa
grafis dan notasi untuk menggambarkan model berorientasi objek (Gomaa, 2011).
Pemodelan dengan UML dapat menghasilkan gambaran yang jelas dan
memberikan kemudahan dalam menganalisa, mendesain, dan
mengimplementasikannya (Sumarta, Siswoyo, & Juhana, 2004).
UML (Unified Modelling Language) merupakan metodologi kolaborasi
antara metode-metode Booch, OMT (Object Modeling Technique), serta OOSE
(Object Oriented Software Engineering) dan beberapa metode lainnya, merupakan
metode yang paling sering digunakan saat ini untuk analisis dan perancangan
sistem dengan metode berorientasi objek (Nugroho, 2009).
UML 2 digambarkan dalam 13 jenis diagram resmi (Fowler, 2003) yang
dapat dilihat pada gambar di bawah ini:
35
Diagram
Structure
Diagram
Behavior
Diagram
Class Diagram
Composite
Structure
Diagram
Component
Diagram
Deployment
Diagram
Object Diagram
Package
Diagram
Activity Diagram
Use Case
Diagram
State Machine
Diagram
Interaction
Diagram
Sequence
Diagram
Communication
Diagram
Interaction
Overview
Diagram
Timing Diagram
Gambar 2. 2 Jenis diagram resmi UML 2
Berikut ini adalah penjelasan diagram-diagram dari gambar 3.1 di atas:
A. Class Diagram
Diagram kelas (Class Diagram) juga merupakan salah satu diagram yang
ada pada UML. Diagram kelas (class diagram) menggambarkan struktur
aplikasi berorientasi objek dari segi pendefinisian kelas-kelas yang akan
dibuat untuk membangun aplikasi. Kelas memiliki apa yang disebut
aribut dan metode/operasi. Atribut merupakan variabel-variabel yang
36
dimiliki oleh suatu kelas. Operasi/metode adalah fungsi-fungsi yang
dimiliki oleh suatu kelas.
B. Component Diagram
Component diagram merupakan diagram UML yang menampilkan
komponen dalam sistem dan hubungan antara mereka. Component
diagram adalah diagram yang digunakan untuk menggambarkan
organisasi dan ketergantungan komponen-komponen software.
Component diagram berguna untuk memodelkan komponen objek. Pada
component view, akan difokuskan pada organisasi fisik sistem. Pertama,
diputuskan bagaimana kelas-kelas akan diorganisasikan menjadi kode
pustaka. Kemudian akan dilihat bagaimana perbedaan antara berkas
eksekusi, berkas Dynamic Link Library (DDL), dan berkas runtime
lainnya dalam sistem.
C. Composite Structure Diagram
Composite structure diagram adalah diagram untuk menunjukkan
dekomposisi secara hierarkis sebuah class ke sebuah struktur internal.
Hal ini memungkinkan untuk memecah objek yang kompleks menjadi
bagian-bagian yang kecil.
D. Deployment Diagram
Deployment diagram menunjukkan tata letak sebuah sistem secara fisik,
menampakkan bagian-bagian software yang berjalan pada bagian-bagian
hardware yang digunakan untuk mengimplementasikan sebuah sistem
dan keterhubungan antara komponen-komponen hardware tersebut.
Deployment diagram dapat digunakan pada bagian-bagian awal proses
perancangan sistem untuk mendokumentasikan arsitektur fisik sebuah
sistem.
E. Object Diagram
Object diagram merupakan sebuah gambaran tentang objek-objek dalam
sebuah sistem pada satu titik waktu. Karena lebih menonjolkan perintah-
perintah daripada class, object diagram lebih sering disebut sebagai
sebuah diagram perintah.
37
F. Package Diagram
Package diagram adalah sebuah bentuk pengelompokan yang
memungkinkan untuk mengambil setiap bentuk di UML dan
mengelompokkan elemen-elemen dalam tingkatan unit yang lebih tinggi.
Kegunaan package yang paling umum adalah untuk mengelompokkan
class.
G. Activity Diagram
Activity diagram digunakan untuk mendokumentasikan alur kerja pada
sebuah sistem, yang dimulai dari pandangan business level hingga ke
operational level. Pada dasarnya, activity diagram merupakan variasi
dari state machine diagram. Activity diagram mempunyai peran seperti
halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah
activity diagram bisa mendukung perilaku paralel sedangkan flowchart
tidak bisa.
H. Use Case Diagram
Use case diagram adalah salah satu diagram yang ada dalam UML
(Unified Modeling Language). Use case diagram merupakan merupakan
pemodelan untuk kelakuan (behavior) aplikasi perangkat lunak yang
akan dibuat. Use case diagram mendeskripsikan interaksi antara satu
atau lebih aktor dengan aplikasi yang akan dibuat. Secara kasar, use case
diagram digunakan untuk mengetahui fungsi/proses apa saja yang ada di
dalam sebuah aplikasi dan siapa saja yang berhak menggunakan fungsi-
fungsi atau proses-proses itu.
Ada dua hal utama pada use case diagram yaitu pendefinisian apa yang
disebut aktor dan use case, berikut ini penjelasannya:
a. Aktor merupakan orang, proses, atau aplikasi lain yang berinteraksi
dengan aplikasi yang akan dibuat diluar aplikasi itu sendiri, jadi
walaupun simbol dari aktor adalah gambar orang tapi aktor belum
tentu merupakan orang.
b. Use case merupakan fungsi-fungsi/proses-proses yang disediakan
aplikasi sebagai unit-unit yang saling bertukar pesan/berinteraksi antar
38
unit/proses atau aktor. Syarat penamaan pada use case adalah nama
didefinisikan sesimpel mungkin dan dapat dipahami.
I. State Machine Diagram
State machine diagram digunakan untuk menelusuri individu-individu
objek melalui keseluruhan daur hidupnya, menspesifikasi semua urutan
yang mungkin dari pesan-pesan yang akan diterima objek tersebut
bersama-sama dengan tanggapan atas pesan-pesan tersebut. Diagram
state menggambarkan transisi dan perubahan keadaan suatu objek dalam
sistem sebagai akibat dari stimuli yang diterima. Pada umumnya diagram
ini menggambarkan class tertentu. State diagram membantu analis,
perancang dan pengembang untuk memahami perilaku objek dalam
sistem.
J. Sequence Diagram
Sequence diagram adalah diagram yang digunakan untuk
mendokumentasikan komunikasi/interaksi antarkelas. Diagram ini
menunjukkan sejumlah objek dan message (pesan) yang diletakkan
diantara objek-objek di dalam use case. Perlu diingat bahwa di dalam
diagram ini, kelas-kelas dan aktor-aktor diletakkan di bagian atas
diagram dengan urutan dari kiri ke kanan dengan garis lifeline yang
diletakkan secara vertikal terhadap kelas dan aktor.
K. Communication Diagram
Communication diagram atau collaboration diagram juga
menggambarkan interaksi antarobjek seperti sequence diagram, tetapi
lebih menekankan pada peran masing-masing objek dan bukan pada
waktu penyampaian message (pesan). Setiap message memiliki sequence
number, di mana message dari level tertinggi memiliki nomor 1.
Messages dari level yang sama memiliki prefiks yang sama.
L. Interaction Overview Diagram
Interaction overview diagram adalah pencangkokan secara bersama
antara activity diagram dengan sequence diagram. Interaction overview
diagram dapat dianggap sebagai activity diagram di mana semua
aktivitas diganti dengan sedikit sequence diagram, atau bisa juga
39
dianggap sebagai sequence diagram yang dirincikan dengan notasi
activity diagram yang digunakan untuk menunjukkan aliran pengawasan.
M. Timing Diagram
Timing diagram adalah bentuk lain dari interaction diagram, di mana
fokus utamanya lebih ke waktu. Timing diagram sangat berdaya guna
dalam menunjukkan faktor pembatas waktu di antara perubahan state
pada objek yang berbeda.
2.8 MVC (Model-View-Controller)
Model-View-Controller (MVC) adalah pola desain atau arsitektur yang
digunakan dalam rekayasa perangkat lunak, di mana terjadi pemisahan yang jelas
antara data (model), dengan user interface (view) (Widiyanto, 2010). MVC adalah
metode untuk membuat aplikasi dengan memisahkan data (model) dari tampilan
(view) dan bagaimana memprosesnya (controller) (Utpatadevi, Sudana, &
Cahyawan, 2012). Jadi MVC merupakan metode dalam pemrograman yang
memisahkan suatu program menjadi beberapa bagian, yaitu bagian model, bagian
view, dan bagian controller. Biasanya bagian model diisi dengan fungsionalitas
program tersebut, bagian view berisi tentang user interface dari program, dan
bagian controller berisi tentang penanganan event dari program tersebut.
Alasan utama mengapa setiap orang yang mencoba membuat user interface
(antarmuka pengguna) dengan bahasa-bahasa pemrograman berorientasi objek,
misalnya Java dengan Abstract Window Toolkits (AWT) dan Java Foundation
Class (JFC), cukup menemui kesulitan berarti. Dalam hal ini, IDE (Integrated
Development Environment) java terbaru misalnya NetBeans dan Eclipse, yang
memuat plugin visual editor, bisa memuat interface yang lebih mudah dengan
fitur drag and drop. Namun, hasil perancangan pada umumnya masih terasa sulit
untuk dipelihara, untuk dilacak kesalahannya, dan sering tidak dapat digunakan
ulang.
Sementara itu, kita akan mendapatkan keuntungan ketika kita dapat
memisahkan komponen-komponen antarmuka berbasis Graphical User Interface
(GUI) dengan logika bisnisnya. Untuk itu kita gunakan model Model-View-
40
Controller (MVC), yang memisahkan komponen-komponen persentasi suatu
aplikasi dengan komponen-komponen logika bisnisnya.
Arsitektur MVC ini memungkinkan adanya perubahan dalam domain model
tanpa harus mengubah kode untuk menampilkan domain model tersebut. Hal ini
sangat bermanfaat ketika aplikasi mempunyai domain model dan view komponen
sangat besar dan kompleks.
Gambar 2. 3 Model MVC (Model View Controller)
Beberapa alasan pokok mengapa model MVC menjadi sangat bermanfaat
yaitu:
a. penggunaan ulang komponen-komponen antarmuka pengguna
b. kemampuan untuk mengembangkan aplikasi dengan antarmuka
pengguna secara terpisah
c. kemampuan untuk melakukan pewarisan dari berbagai bagian yang
berbeda pada suatu hierarki kelas
d. kemampuan untuk mendefinisikan kelas-kelas pengaturan tampilan yang
menyediakan fitur-fitur umum secara terpisah dengan bagimana fitur-
fitur itu akan ditampilkan oleh aplikasi yang kita kembangkan
41
2.9 Pengujian (Testing)
Pengujian (testing) adalah tindakan untuk memeriksa/membuktikan bahwa
kualitas software telah terpenuhi, dan pengimplementasian software telah benar
sesuai dengan syarat/kebutuhan (O’Regan, 2011). Ada beberapa tipe pengujian
(testing), yaitu pengujian unit (unit testing), pengujian integrasi (integration
testing), pengujian sistem (system testing), pengujian daya guna (performance
testing), dan pengujian penerimaan pengguna (user acceptance testing).
Tujuan akhir dari pengujian (testing) adalah untuk memastikan bahwa
sistem bekerja/berjalan sesuai dengan perencanaan, dan secara umum untuk
memastikan agar dapat memenuhi kebutuhan pengguna (Davis & Yen, 1998).
Lebih khusus, pengujian (testing) adalah proses mencoba meletakkan sistem dan
beserta komponen pendukungnya, mengamati, dan memperbaiki kesalahan atau
cacat yang timbul.
Pengujian perangkat lunak (software testing) berperan dalam memastikan
bahwa produk perangkat lunak telah berkualitas tinggi dan sesuai dengan kualitas
yang diharapan oleh pelanggan (O’Regan, 2011).
2.9.1 Tujuan Pengujian
Pengujian merupakan bagian yang bersifat integral dalam pengembangan
perangkat lunak, dan lebih dari 50% waktu pengembangan dihabiskan untuk
pengujian (Simarmata, 2010). Adapun tujuan dari pengujian adalah:
a. Untuk meningkatkan kualitas
Software berkualitas adalah software yang tidak memiliki cacat, dan
sesuai dengan kebutuhan. Bug dapat menyebabkan kerugian yang besar,
menghancurkan, dan menyebabkan masalah. Debugging sering dilakukan
untuk mengetahui perancangan yang cacat dari pemrograman.
Menemukan masalah dan memperbaikinya adalah tujuan dari debugging
di dalam tahapan pemrograman.
b. Untuk verifikasi dan validasi
Pengujian software juga bertujuan untuk memvalidasi dan memverifikasi
software (perangkat lunak), yaitu apakah software yang dikembangkan
telah memenuhi persyaratan bisnis dan teknis (sesuai dengan desain dan
42
pengembangan yang direncanakan), apakah sudah bekerja seperti yang
diharapkan, dan dapat diimplementasikan dengan karakteristik yang
sama.
c. Untuk keandalan estimasi
Pengujian dapat digunakan untuk memperoleh data statistik yang dapat
digunakan untuk mengetahui kegagalan, atau estimasi keandalan
perangkat lunak. Keandalan perangkat lunak merupakan hal yang penting
karena memiliki hubungan dengan berbagai aspek dari perangkat lunak,
termasuk struktur.
2.9.2 Jenis Pengujian
2.9.2.1 Pengujian Black Box
Pengujian black box mencakup beberapa pengujian (Simarmata, 2010),
yaitu:
a. Pengujian fungsionalitas (functional testing)
Pengujian fungsional dilakukan untuk menguji persyaratan fungsional,
yaitu dilakukan dalam bentuk tertulis untuk memeriksa apakah aplikasi
berjalan seperti yang diharapkan. Pengujian fungsional meliputi seberapa
baik system melaksanakan fungsinya, termasuk perintah-perintah
pengguna, manipulasi data, pencarian dan proses bisnis, pengguna layar,
dan integrasi.
b. Pengujian tegangan (stress testing)
Pengujian tegangan ditujukan untuk menguji kualitas aplikasi dalam
lingkungannya. Pengujiannya dilakukan dengan menjalankan aplikasi
dengan menuntut untuk melakukan melebihi beban normal. Ini adalah
pengujian yang cukup sulit, cukup komplek, dan memerlukan upaya
bersama dari semua tim.
c. Pengujian beban (load testing)
Pengujian ini dilakukan dengan memberikan beban berat, seperti pada
pengujian situs web, dengan tujuan untuk mengetahui apakah kinerja
aplikasi akan mengalami penurunan atau tidak.
43
d. Pengujian khusus (ad-hoc testing)
Pengujian ini dilakukan tanpa membuat rencana pengujian (test plan)
atau kasus pengujian (test case). Pengujian ini dilakukan untuk
membantu penguji mempelajari aplikasi sebelum melakukan pengujian
dengan metode pengujian lain. Pengujian ini kadang dilakukan untuk
membantu dalam mempelajari aplikasi jika dokumentasi sulit dimengerti.
e. Pengujian penyelidikan (exploratory testing)
Pengujian penyelidikan mirip dengan pengujian khusu dan dilakukan
untuk mempelajari aplikasi. Pengujian ini merupakan pendekatan yang
menyenangkan untuk pengujian.
f. Pengujian usabilitas (usability testing)
Pengujian ini disebut juga sebagai pengujian untuk keakraban pengguna
(testing for user-friendliness). Pengujian ini dilakukan jika antarmuka
pengguna dari aplikasi dianggap penting dan harus spesifik untuk jenis
pengguna tertentu. Pengujian ini ditujukan untuk menghilangkan
kesulitan pengguna dalam menggunakan aplikasi.
g. “Pengujian asap” (smoke testing)
Pengujian ini disebut juga pengujian kenormalan (sanity testing).
Pengujian ini dilakukan untuk memeriksa apakah aplikasi telah siap
untuk dilakukan pengujian yang lebih besar dan bekerja sampai tingkat
yang diharapkan.
h. Pengujian pemulihan (recovery testing)
Pengujian pemulihan (recovery testing) pada dasarnya dilakukan untuk
memeriksa seberapa cepat dan baiknya aplikasi bias dipulihkan terhadap
semua jenis crash atau kegagalan hardware, masalah bencana, dan lain-
lain. Jenis atau taraf pemulihan ditetapkan dalam persyaratan spesifikasi.
i. Pengujian volume (volume testing)
Pengujian volume dilakukan terhadap efisiensi dari aplikasi. Jumlah data
yang besar diproses melalui aplikasi (yang sedang diuji) untuk
memeriksa keterbatasan ekstrem dari aplikasi. Pengujian volume
ditujukan untuk memastikan batas-batas fisik dan logis untuk kapasitas
44
sistem, dan memastikan apakah batasan dapat diterima untuk memenuhi
proyeksi kapasitas dari pengolahan bisnis organisasi.
j. Pengujian domain (domain testing)
Pengujian domain merupakan pengujian yang paling sering dijelaskan
dalam teknik pengujian. Pengujian dilakukan dengan mengambil ruang
pengujian dari variabel individu dan membaginya dalam subset (dalam
beberapa cara) yang sama, kemudian menguji perwakilan dari masing-
masing subset.
k. Pengujian skenario (scenario testing)
Pengujian skenario merupakan definisi dari serangkaian kasus uji atau
skrip tes dan urutan di mana mereka dieksekusi. Pengujian skenario
merupakan pengujian yang realistis, kredibel, dan memotivasi
stakeholder, tantangan untuk program dan mempermudah penguji untuk
melakukan evaluasi.
l. Pengujian regresi (regression testing)
Pengujian regresi adalah gaya pengujian yang berfokus pada pengujian
ulang (retesting) setelah ada perubahan. Pada pengujian regresi
berorientasi risiko (risk-oriented regression testing), daerah yang sama
yang sudah diuji, akan kita uji lagi dengan pengujian yang berbeda
(semakin kompleks).
m. Penerimaan pengguna (user acceptance)
Pada jenis pengujian ini, perangkat lunak akan diserahkan kepada
pengguna untuk mengetahui apakah perangkat lunak memenuhi harapan
pengguna dan bekerja seperti yang diharapkan.
n. Pengujian alfa (alpha testing)
Pada jenis pengujian ini, pengguna akan diundang ke pusat
pengembangan. Pengguna akan menggunakan aplikasi dan pengembang
mencatat setiap masukan atau tindakan yang dilakukan oleh pengguna.
o. Pengujian beta (beta testing)
Pada jenis pengujian ini, perangkat lunak didistribusikan sebagai sebuah
versi beta dengan pengguna yang menguji aplikasi di situs mereka.
Pengecualian/cacat yang terjadi akan dilaporkan kepada pengembang.
45
2.9.2.2 Pengujian White Box
Sedangkan pengujian white box mencakup beberapa pengujian (Simarmata,
2010), antara lain:
a. Pengujian unit (unit testing)
Pengujian unit bertujuan untuk memeriksa apakah modul tertentu atau
kode unit bekerja dengan baik. Pengujian unit berada pada tingkat yang
sangat dasar seperti ketika unit dikembangkan atau fungsi tertentu
dibangun. Pengujian unit berkaitan dengan unit secara keseluruhan, hal
ini akan menguji interaksi antara berbagai fungsi, tetapi membatasi
pengujian dalam satu unit. Lingkup yang tepat dari unit ditinggalkan
kepada interpretasi, pendukung kode pengujian, kadang-kadang disebut
perancah (scaffolding), mungkin diperlukan untuk mendukung setiap
pengujian. Pengujian ini digerakkan oleh tim arsitektur dan
implementator.
b. Analisis statis dan dinamis (static and dynamic analysis)
Analisis statis dilibatkan melalui kode untuk mengetahui segala
kemungkinan cacat dalam kode, sedangkan analisis dinamis akan
melibatkan pelaksanaan kode dan penganalisisan hasilnya.
c. Cakupan pernyataan (statement coverage)
Pengujian pernyataan dilakukan dengan menjalankan minimal sekali
untuk setiap pernyataan dalam aplikasi. Pengujian ini untuk memastikan
bahwa setiap pernyataan tidak memiliki efek samping yang belum
diprediksi.
d. Cakupan cabang (branch coverage)
Pengujian cakupan cabang ditujukan untuk membantu memvalidasi
setiap percabangan, dan memastikan bahwa tidak ada cabang yang
mengarah ke perilaku abnormal dari aplikasi.
e. Pengujian mutasi (mutation testing)
Pengujian ini dilakukan untuk menguji kode yang telah dimodifikasi
setelah memperbaiki bug (cacat) tertentu. Hal ini juga membantu dalam
menemukan mana kode dan strategi pengkodean yang dapat membantu
dalam mengembangkan fungsi tersebut secara efektif.
46
2.10 Aplikasi Pendukung
2.10.1 Java
Java merupakan sebuah bahasa pemrograman berorientasi objek yang dapat
berjalan pada platform yang berbeda, baik di Windows, Linux, serta sistem
informasi lainnya (Supriyanto, 2010). Jadi sebuah source code aplikasi yang sama
dapat di-compile dan dijalankan di berbagai platform. Hal ini dapat
mempermudah pendistribusiannya.
2.10.1.1 Karakteristik Java
Java memiliki karakteristik yang berlebih dibanding bahasa pemrograman
lain (Utomo, 2009), yaitu:
a. Sederhana
Bahasa pemrograman Java menggunakan sintaks mirip dengan C++
namun sintaks pada Java telah banyak diperbaiki terutama
menghilangkan penggunaan pointer yang rumit dan multiple inheritance.
Java juga menggunakan automatic memory allocation dan memory
garbage collection.
b. Berorientasi objek (object oriented)
Java mengunakan pemrograman berorientasi objek yang membuat
program dapat dibuat secara modular dan dapat dipergunakan kembali.
Pemrograman berorientasi objek memodelkan dunia nyata ke dalam
objek dan melakukan interaksi antar objek-objek tersebut.
c. Dapat didistribusi dengan mudah
Java dibuat untuk membuat aplikasi terdistribusi secara mudah dengan
adanya libraries networking yang terintegrasi pada Java.
d. Interpreter
Program Java dijalankan menggunakan interpreter yaitu Java Virtual
Machine (JVM). Hal ini menyebabkan source code Java yang telah
dikompilasi menjadi Java bytecodes dapat dijalankan pada platform yang
berbeda-beda.
47
e. Robust
Java mempuyai reliabilitas yang tinggi. Compiler pada Java mempunyai
kemampuan mendeteksi error secara lebih teliti dibandingkan bahasa
pemrograman lain. Java mempunyai runtime-Exception handling untuk
membantu mengatasi error pada pemrograman.
f. Aman
Sebagai bahasa pemrograman untuk aplikasi internet dan terdistribusi,
Java memiliki beberapa mekanisme keamanan untuk menjaga aplikasi
tidak digunakan untuk merusak sistem komputer yang menjalankan
aplikasi tersebut.
g. Arsitektur netral
Program Java merupakan platform independent. Program cukup
mempunyai satu buah versi yang dapat dijalankan pada platform yang
berbeda dengan Java Virtual Machine (JVM).
h. Portabel
Source code maupun program Java dapat dengan mudah dibawa ke
platform yang berbeda-beda tanpa harus dikompilasi ulang.
i. Performance
Performance pada Java sering dikatakan kurang tinggi. Namun
performance Java dapat ditingkatkan menggunakan kompilasi Java lain
seperti buatan Inprise, Microsoft ataupun Symantec yang menggunakan
Just In Time Compilers (JIT).
j. Multithreaded
Java mempunyai kemampuan untuk membuat suatu program yang dapat
melakukan beberapa pekerjaan secara sekaligus dan simultan.
k. Dinamis
Java didesain untuk dapat dijalankan pada lingkungan yang dinamis.
Perubahan pada suatu class dengan menambahkan properties ataupun
method dapat dilakukan tanpa menggangu program yang menggunakan
class tersebut.
48
2.10.1.2 Sistem Kerja Java
Java merupakan bahasa pemrograman yang terdiri dari compiler dan
interpreter (Utomo, 2009), compiler menerjemahkan kode sumber program java
menjadi bytecode. Untuk menjalankan bytecode hasil compiler diperlukan java
interpreter, sehingga menjadikan java dapat dijalankan di berbagai platform. Java
interpreter dapat dijalankan langsung dari command prompt; atau applet viewer
atau web browser (untuk applet).
Kelemahan adalah kecepatan eksekusi program akan lebih lambat dari
program biasa karena program bytecode harus diterjemahkan terlebih dahulu oleh
interpreter, kemudian dijalankan pada hardware.
Gambar di bawah ini menjelaskan aliran proses kompilasi dan eksekusi
sebuah program Java :
Gambar 2. 4 Proses dari sebuah Program Java
Langkah pertama dalam membuat sebuah program berbasis Java adalah
menuliskan kode program pada text editor. Contoh text editor yang dapat
digunakan antara lain, notepad, vi, emacs dan lain sebagainya. Kode program
yang dibuat kemudian disimpan dalam sebuah berkas berekstensi .java.
Setelah membuat dan menyimpan kode program, kompilasi file yang berisi
kode program tersebut dengan menggunakan Java Compiler. Hasil dari kompilasi
berupa berkas bytecode dengan ekstensi .class.
Berkas yang mengandung bytecode tersebut kemudian akan dikonversikan
oleh Java Interpreter menjadi bahasa mesin sesuai dengan jenis dan platform
yang digunakan.
49
Tabel 2. 1 Tahapan pembuatan program java
Proses Tool Hasil
Menulis kode program Text editor Berkas berekstensi .java
Kompilasi program Java Compiler Berkas berekstensi .class
(Java Bytecodes)
Menjalankan program Java Interpreter Program Output
Program java bersifat cross-platform digambarkan pada gambar 2.4, sebuah
source code java dapat di-compile dan dijalankan pada berberapa platform, tanpa
mengubah kode program. Hal ini dapat mengefisienkan waktu pengembangan jika
akan diimplementasikan pada beberapa platform.
Gambar 2. 5 Java Cross-platform atau Multi-platform
2.10.1.3 Teknologi Java
Teknologi java merupakan sebuah bahasa pemrograman yang
multiplatform. Bahasa pemrograman java merupakan bahasa tingkat tinggi yang
memiliki berbagai karakteristik seperti yang telah dijelaskan sebelumnya.
Platform adalah lingkungan perangkat keras atau lunak di mana program
berjalan. Kita sudah mengenal beberapa platform yang paling populer seperti
Microsoft Windows, Linux, Solaris OS, dan Mac OS. Kebanyakan platform dapat
50
digambarkan sebagai kombinasi dari sistem operasi dan perangkat keras yang
mendasarinya. Platform Java berbeda dari platform lainnya, karena hanya
merupakan platform perangkat lunak yang berjalan di atas platform hardware
lainnya.
Java platform terdiri dari dua komponen, yaitu Java Virtual Machine (JVM)
dan Aplication Programming Interface (API). Secara garis besar teknologi Java
terbagai menjadi beberapa bagian (Utomo, 2009), yaitu seperti di bawah ini:
a. J2SE (2 Platform Standard Edition)
Teknologi Java ini dirancang untuk membuat aplikasi yang berjalan pada
PC dan workstation yang berada pada platform Windows, Linux,
Macintos. J2SE terbagi menjadi dua bagian besar yaitu J2SE Core dan
J2SE Desktop.
J2SE Core digunakan untuk teknologi security, debugging, database dan
sebagainya. Sedangkan teknologi J2SE Desktop meliputi beberapa
teknologi yaitu JRE (Java Runtime Environment), JFC (Java Foundation
Classes), Java Sound API dan sebagainya.
b. J2EE (2 Platform Enterprise Edition)
Teknologi Java ini digunakan untuk pengembangan aplikasi-aplikasi
enterprise, meliputi beberapa teknologi yaitu JSP (Java Server Pages),
Java Servlet, CORBA (untuk aplikasi terdistribusi) dan sebagainya.
c. J2ME (Java 2 Platform Micro Edition)
Teknologi Java ini digunakan untuk pengembangan sistem mikro dan
sistem embedded seperti handphone, PDA dan lain sebagainya. Meliputi
dua bagian besar yaitu CLDC (MIDP, BlueTooth dan lainnya) dan CDC
Technology (JDBC/teknologi database dan RMI).
d. Java Web Services
Merupakan aplikasi web berbasis enterprise dengan standar XML dan
protokol tertentu untuk bertukar data dengan klien. Teknologi ini
meliputi beberapa API yang dirancang untuk bekerja dengan XML
seperti Java API for XML Based RPC (JAX-RPC), Java API for XML
Based Messaging (JAXM), Java API for XML Processing (JAXP) dan
Java API for XML Binding (JAXB).
51
2.10.2 NetBeans
Editor NetBeans cukup luar biasa untuk membuat aplikasi java, karena
didukung fasilitas drag and drop komponen, yaitu dukungan rapid application
development (pemrograman berbasis visual) (Huda & Komputer, 2009). NetBeans
IDE (Integrated Development Environment) adalah sebuah lingkungan
pengembangan terintegrasi yang tersedia untuk Windows, Mac, Linux, dan
Solaris. NetBeans adalah salah satu aplikasi IDE yang digunakan programmer
untuk menulis, meng-compile, mencari kesalahan, dan menyebarkan program.
Proyek NetBeans terdiri dari open-source IDE dan platform aplikasi, yang
memungkinkan pengembang untuk secara cepat membuat web, enterprise,
desktop, dan aplikasi mobile menggunakan platform Java, serta JavaFX, PHP,
JavaScript dan Ajax, Ruby dan Ruby on Rails, Groovy dan Grails, dan C/C++.
NetBeans menyajikan alat pemrograman GUI (Graphical User Interface)
dan berbagai wizard yang sangat memudahkan dalam membangun program java
(Wijono, Suharto, & Wijono, 2007). NetBeans ditulis dalam bahasa java namun
dapat juga mendukung bahasa pemrogramman lain. Program ini bersifat kode
terbuka (open source) dan bebas (free) untuk penggunaan komersial dan
nonkomersial. Kode sumber tersedia untuk guna ulang dengan lisensi Common
Development and Distribution License (CDDL).
Proyek NetBeans didukung oleh komunitas pengembang yang ekstensif dan
menawarkan dokumentasi dan sumber daya pelatihan serta beragam pilihan
plugin dari pihak ketiga.
2.10.3 MySQL
MySQL adalah sebuah perangkat lunak sistem manajemen basis data SQL
atau DBMS yang multi-thread dan multi-user. MySQL adalah Relation Database
Management System (RDBMS) yang didistribusikan secara gratis di bawah lisensi
General Public License (GPL), sehingga setiap orang bebas untuk menggunakan
MySQL (Supriyanto, 2010).
MySQL (My Structured Query Language) merupakan sebuah program
pembuat database yang bersifat open source, artinya semua orang dapat
menggunakan dan dapat dijalankan pada semua platform baik windows maupun
52
LINUX/UNIX. Suatu database relationship menyimpan data dalam tabel yang
terpisah. Tabel-tabel tersebut terhubungkan oleh suatu relasi terdefinisi yang
memungkinkan user memperoleh kombinasi data dari beberapa tabel dalam suatu
permintaan.
MySQL sebenarnya merupakan Database Management System (DBMS)
yang dikembangkan dari bahasa SQL (Structured Query Language) (Prasetyo,
2004). SQL adalah bahasa terstruktur yang digunakan untuk query, meng-update,
dan memanipulasi database (Alam, 2005). SQL adalah sebuah konsep
pengoperasian database, terutama untuk pemilihan atau seleksi dan pemasukan
data, yang memungkinkan pengoperasian data dikerjakan dengan mudah secara
otomatis. Keandalan suatu sistem database (DBMS) dapat diketahui dari cara
kerja optimizer-nya dalam melakukan proses perintah-perintah SQL, yang dibuat
oleh user maupun program-program aplikasinya.
Sebagai database server, MySQL dapat dikatakan lebih unggul
dibandingkan database server lainnya dalam query data. Hal ini terbukti untuk
query yang dilakukan oleh single user, kecepatan query MySQL bisa sepuluh kali
lebih cepat dari PostgreSQL dan lima kali lebih cepat dibandingkan Interbase
Sebenarnya MySQL adalah produk yang berjalan pada platform Linux.
Karena sifatnya yang open source, dia dapat dijalankan pada semua platform baik
Windows maupun Linux. Selain itu, MySQL juga merupakan program pengakses
database yang bersifat jaringan sehingga dapat digunakan untuk aplikasi multi
user (banyak pengguna). Saat ini database MySQL telah digunakan hampir oleh
semua programmer database.
Agar aplikasi java yang dibuat dapat mengakses DBMS MySQL, maka
diperlukan driver untuk menjembataninya (Huda & Komputer, 2009).
2.10.3.1 Kelebihan MySQL
Kelebihan lain dari MySQL adalah menggunakan bahasa query standar
yang dimiliki SQL (Structured Query Language). SQL adalah suatu bahasa
permintaan yang terstruktur yang telah distandarkan oleh semua program
pengakses database seperti Oracle, Posgres SQL, SQL Server, dan lain-lain.
53
Keuntungan-keuntungan yang dapat diperoleh jika menggunakan MySQL
adalah sebagai berikut:
a. Bebas untuk di-download dan didistribusikan
b. Source code-nya bebas untuk dimodifikasi
c. Cepat dan sederhana
d. Stabil dan tangguh
e. Fleksibel dengan berbagai bahasa pemrograman
f. Mempunyai keamanan yang baik
g. Mendapatkan dukungan dari banyak komunitas
h. Kemudahan dalam melakukan manajemen basis data
i. Mendukung banyak transaksi
j. Perkembangan software yang cukup begitu cepat
k. Bagus untuk basis data berbasis web dan bisnis kecil
Selain itu MySQL juga memiliki beberapa keistimewaan yang antara lain:
a. Portability
MySQL dapat berjalan stabil pada berbagai sistem operasi seperti
Windows, Linux, FreeBSD, Mac OS X Server, Solaris, Amiga dan lain-
lain.
b. Open source
MySQL didistribusikan secara open source di bawah lisensi GPL,
sehingga dapat digunakan secara gratis.
c. Multiuser
MySQL dapat digunakan oleh beberapa user dalam waktu yang
bersamaan tanpa mengalami masalah atau konflik.
d. Performance tuning
MySQL memiliki kecepatan yang menakjubkan dalam menangani query
sederhana, dengan kata lain dapat memproses lebih banyak SQL per
satuan waktu.
54
e. Jenis kolom
MySQL memiliki tipe kolom yang sangat kompleks, seperti
signed/unsigned integer, float, double, char, text, date, timestamp dan
lain-lain.
f. Perintah dan fungsi
MySQL memiliki operator dan fungsi secara penuh yang mendukung
perintah SELECT dan WHERE dalam perintah (query).
g. Keamanan
MySQL memiliki beberapa lapisan keamanan seperti level subnetmask,
nama host, dan izin akses user dengan sistem perizinan yang mendetil
serta password terenkripsi.
h. 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.
i. Konektivitas
MySQL dapat melakukan koneksi dengan client menggunakan protokol
TCP/IP, Unix soket (UNIX), atau Named Pipes (NT).
j. Lokalisasi
MySQL dapat mendeteksi pesan kesalahan pada client dengan
menggunakan lebih dari dua puluh bahasa.
k. Antarmuka
MySQL memiliki antarmuka terhadap berbagai aplikasi dan bahasa
pemrograman dengan menggunakan fungsi API (Application
Programming Interface).
l. 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.
55
m. Struktur tabel
MySQL memiliki struktur tabel yang lebih fleksibel dalam menangani
ALTER TABLE, dibandingkan basis data lainnya semacam PostgreSQL
ataupun Oracle.
2.10.3.2 Kekurangan MySQL
Kekurangan-kekurangan dari DBMS MySQL adalah:
a. Tidak cocok untuk menangani data dengan jumlah yang besar, baik untuk
menyimpan data maupun untuk memproses data.
b. Memiliki keterbatasan kemampuan kinerja pada server ketika data yang
disimpan telah melebihi batas maksimal kemampuan daya tampung
server karena tidak menerapkan konsep technology cluster server.
56
BAB III
ANALISA DAN PERANCANGAN
3.1 Analisa
Analisa atau analisis adalah kajian yang dilaksanakan terhadap sebuah
permasalahan guna meneliti struktur masalah secara mendalam dengan cara
memecah-mecah masalah tersebut menjadi bagian-bagian kecil yang lebih mudah
dipelajari, kemudian mempelajarinya dan mengambil kesimpulan.
3.1.1 Analisa Sistem Saat Ini
Pendaftaran calon siswa dilakukan pada tiap awal tahun ajaran baru. Calon
siswa yang ingin mendaftar mendatangi tempat pendaftaran, kemudian
mengambil formulir pendaftaran. Formulir pendaftaran yang telah diambil diisi
selengkap mungkin. Formulir yang telah diisi dan persyaratan lainnya diserahkan
kembali ke bagian pendaftaran.
Setelah pendaftaran ditutup, selanjutnya panitia penerimaan siswa baru
melakukan seleksi terhadap calon siswa yang telah mendaftar dengan mengikuti
ketentuan yang telah ditetapkan. Cara melakukan seleksi calon siswa yaitu dengan
mengurutkan calon siswa berdasarkan nilai ujian nasional, kemudian diambil yang
tertinggi sesuai daya tampung kelas yang tersedia. Hasil dari seleksi calon siswa
kemudian diumumkan di papan pengumuman. Calon siswa yang dinyatakan
diterima kemudian melakukan pendaftaran ulang.
Pembayaran dilakukan di ruang TU (tata usaha) sesuai jadwal yang telah
ditentukan. Ada beberapa jenis pembayaran yang harus dilakukan oleh siswa,
yaitu uang gedung, SPP (Sumbangan Pengembangan Pendidikan), biaya ujian
tengah semester, biaya ujian akhir semester, dan lain-lain.
Setiap akhir semester dibuat laporan nilai hasil belajar siswa berupa raport
untuk orang tua atau wali murid siswa. Nilai dikelola oleh guru masing-masing
mata pelajaran dan diserahkan ke wali kelas untuk ditulis ke dalam raport di akhir
semester. Nilai dihitung berdasarkan nilai tugas, nilai ulangan, nilai ujian tengah
semester, dan nilai ujian akhir semester.
57
Proses (aktivitas) dari sistem yang berjalan saat ini dapat digambarkan
dalam diagram activity (aktivitas) sebagai berikut:
Gambar 3. 1 Diagram activity (aktivitas) sistem saat ini
3.1.2 Analisa Data/Dokumen
Data-data yang dicatat dalam form pendaftaran adalah biodata calon siswa,
nilai ujian nasional, peminatan/jurusan yang dipilih, dan lain-lain. Biodata calon
siswa antara lain no. pendaftaran, nama lengkap, alamat, tempat dan tanggal lahir,
asal sekolah, tahun lulus, dan lain-lain.
act Business Process Model
Start
Calon siswa melakukan
pendaftaran
Calon siswa mengisi form dan
melengkapi persyaratan
Calon siswa menyerahkan
form pendaftaran dan
melengkapi persyaratan
Staf administrasi
mengecek formulir dan
persyaratan
Data siswa di-input dan diolah
menggunakan Ms. Excel untuk
menetapkan calon siswa yang diterima
Calon siswa yang diterima
diumumkan
Siswa melakukan
pembayaran
Data pembayaran dicatat
dalam buku jurnal
pembayaran
Data pembayaran direkap
dan dimasukkan ke dalam
buku besar
Data pembayaran di-input dan
diolah menggunakan Ms. Excel
untuk membuat laporan
Membuat jadwal
belajar/mengajar
Meng-input dan
mengolahnya
menggunakan Ms. Excel
Mencetak dan
mengumumkan
Guru mengolah dan
membuat rekap nilai
siswa
Guru menulis ke
dalam raport siswa
Raport diberikan kepada
orang tua atau wali siswa
Selesai
Guru menetapkan
kelulusan siswa
58
Sedangkan data-data yang dicatat ketika melakukan pembayaran antara lain
jenis pembayaran, besar pembayaran, dan tanggal pembayaran. Untuk aplikasi
yang akan dibuat, akan ditambahkan petugas/staf TU (Tata Usaha) yang
menerima pembayaran.
Pada pencatatan nilai, data-data yang dicatat adalah rincian dari penilaian
siswa, yaitu nilai tugas, nilai ulangan, nilai ujian tengah semester, dan nilai ujian
akhir semester.
3.1.3 Analisa Kebutuhan
Analisa kebutuhan merupakan langkah awal untuk menentukan gambaran
perangkat lunak yang akan dihasilkan ketika pengembang melaksanakan sebuah
proyek pembuatan perangkat lunak. Analisa kebutuhan adalah sebuah proses
untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang
diinginkan klien/pengguna.
Pada pengembangan aplikasi administrasi sekolah ini, spesifikasi dari
perangkat lunak yang akan dibuat adalah:
a. Aplikasi dikembangkan menggunakan arsitektur client-server agar dapat
digunakan oleh beberapa pengguna secara bersamaan sehingga dapat
mempercepat pekerjaan.
b. Aplikasi dikembangkan menggunakan arsitektur MVC (Model View
Controller) agar di masa depan mudah untuk dikembangkan kembali
jika ada kebutuhan tambahan.
c. Aplikasi yang dikembangkan mencakup administrasi pendaftaran siswa,
seleksi/penerimaan siswa, pembayaran, administrasi nilai, dan
pengaturan hak akses pengguna.
3.2 Perancangan
Setelah dilakukan analisa terhadap kebutuhan dan data/dokumen,
selanjutnya dibuat perancangan basis data dan perancangan aplikasi.
59
3.2.1 Perancangan Database (Basis Data)
Perancangan basis data dilakukan dengan membuat beberapa diagram, yaitu
ERD, transformasi ERD ke LRS, dan diagram LRS.
3.2.1.1 ERD (Entity Relationship Diagram)
Berdasarkan analisa kebutuhan yang telah dilakukan, maka dibuat ERD
seperti berikut ini:
60
Jenis Persyaratan
Calon Siswa
Memiliki
Staf Administrasi
Siswa
Jenis Pembayaran
Melakukan
terdiri
PembayaranMenerima
Kelas
Menempati
Jurusan
Memilih
Untuk
JadwalGuru Mengajar
Jam Sesuai
Mata Pelajaran
Kelompok Mata
Pelajaran
Menempati
Termasuk
Mendapat
Untuk
* kd_jpers
Nm_jpers
Stn_pers
Jmlh_pers
* kd_cs
* kd_jpers
* kd_cs
nm_cs
almt_cs
tmp_lhr_cs
tgl_lhr_cs
asl_sklh_cs
thn_lls_cs
nli_ujn_nsnl_cs
* no_peg
nm_peg
almt_peg
tmp_lhr_peg
tgl_lhr_peg
Pass_peg
* kd _jpem
nm _jpem
bsr_pem
Bts_pem
* no_pem
nis
wkt_pem
no_ peg
* nis
nm_sis
almt_sis
tmp_lhr_sis
tgl_lhr_sis
asl_sklh_sis
thn_lls_sis
nli_ujn_nsnl_sisl
thn_msk_sis
* no_pem
* kd_jpem
* kd_jrsn
Nm_jrsn
* kd_kls
nm_kls
dy_tmpng
* kd_jdwl
hri
kd_jm
kd_matpel
nig
* nig
nm_gru
almt_gru
tmp_lhr_gru
tgl_lhr_gru
pass_gru
* kd_jm
ktrngn
mlai
slsai
* nis
* kd_mtpel
tgs
ulngn
uts
uas
* nis
* kd_kls
* kd_klmpk
Nm_klmpk
* kd_matpel
nm_matpel
kd_klmpk
nli_kkm
1
M
1
1
M
MM
M
M
MM
M
1
1
1
1
M
M
M
M
M
M
M
1
M
1
Gambar 3. 2 ERD basis data administrasi sekolah
61
3.2.1.2 ERD ke LRS
Hasil perancangan basis data berupa ERD (Entity Relationship Diagram)
kemudian ditransformasi ke bentuk LRS (Logical Record Structure) sebagai
berikut:
Jenis Persyaratan
Calon Siswa
Memiliki
Staf Administrasi
Siswa
Jenis Pembayaran
Melakukan
terdiri
PembayaranMenerima
Kelas
Menempati
Jurusan
Memilih
Untuk
Jadwal
Guru
Mengajar
Jam
Sesuai
Mata Pelajaran
Kelompok Mata
Pelajaran
Menempati
Termasuk
Mendapat
Untuk
* kd_jpers
Nm_jpers
Stn_pers
Jmlh_pers
* kd_cs
* kd_jpers
* kd_cs
nm_cs
almt_cs
tmp_lhr_cs
tgl_lhr_cs
asl_sklh_cs
thn_lls_cs
nli_ujn_nsnl_cs
* no_peg
nm_peg
almt_peg
tmp_lhr_peg
tgl_lhr_peg
Pass_peg
* kd _jpem
nm _jpem
bsr_pem
Bts_pem
* no_pem
nis
wkt_pem
no_ peg
* nis
nm_sis
almt_sis
tmp_lhr_sis
tgl_lhr_sis
asl_sklh_sis
thn_lls_sis
nli_ujn_nsnl_sisl
thn_msk_sis
* no_pem
* kd_jpem
* kd_jrsn
Nm_jrsn
* kd_kls
nm_kls
dy_tmpng
* kd_jdwl
hri
kd_jm
kd_matpel
nig
* nig
nm_gru
almt_gru
tmp_lhr_gru
tgl_lhr_gru
pass_gru
* kd_jm
ktrngn
mlai
slsai
* nis
* kd_mtpel
tgs
ulngn
uts
uas
* nis
* kd_kls
* kd_klmpk
Nm_klmpkl
* kd_matpel
nm_matpel
kd_klmpk
nli_kkm
1
M
1
1
M
MM
M
M
MM
M
1
1
1
1
M
M
M
M
M
M
M
1
M
1
Gambar 3. 3 ERD ke LRS basis data administrasi sekolah
62
3.2.1.3 LRS (Logical Record Structure)
Setelah proses transformasi dari ERD ke LRS maka diperoleh diagram
relasi seperti gambar berikut ini:
Persyaratan
* kd_cs
* kd_jpers
stts
Jenis Persyaratan
* kd_jpers
Nm_jpers
Stn_pers
Jmlh_pers
Calon Siswa
* kd_cs
nm_cs
almt_cs
tmp_lhr_cs
tgl_lhr_cs
asl_sklh_cs
thn_lls_cs
nli_ujn_nsnl_cs
* kd_jrsn
Jurusan
* kd_jrsn
Nm_jrsn
Siswa
* nis
nm_sis
almt_sis
tmp_lhr_sis
tgl_lhr_sis
asl_sklh_sis
thn_lls_sis
nli_ujn_nsnl_sisl
thn_msk_sis
Staf Administrasi
* no_peg
nm_peg
almt_peg
tmp_lhr_peg
tgl_lhr_peg
Pass_peg
Jenis Pembayaran
* kd_jpem
* nm_jpem
bsr_pem
bts_pem
Detil Pembayaran
* no_pem
* kd_jpem
Pembayaran
* no_pem
* nis
wkt_pem
* no_peg
Nilai
* nis
* kd_mtpel
tgs
ulngn
uts
uas
Kelas
* kd_kls
* kd_jrsn
nm_kls
dy_tmpng
Kelas Siswa
* nis
* kd_kls
Jadwal
* kd_jdwl
* kd_kls
hri
* kd_jm
* kd_matpel
* nig
Guru
* nig
nm_gru
almt_gru
tmp_lhr_gru
tgl_lhr_gru
pass_gru
Jam
* kd_jm
ktrngn
mlai
slsai
Kelompok Mata Pelajaran
* kd_klmpk
Nm_klmpk_matpel
Mata Pelajaran
* kd_matpel
nm_matpel
nli_kkm
* kd_klmpk
M
1
M 1
1
1
1
M
M 1
M
M1
M
1
M
1
M
1
M
1
M
1
M1
1
M
M
M
1
1 M
M
1
* kd_jpers
* kd_cs * kd_jpem
* no_pem
* no_peg
* kd_jrsn
*kd_jrsn
* kd_kls
* nis
* nis
* nis
* nig
* kd_jm
* kd_klmpk
* kd_matpel
* kd_matpel
* kd_kls
Gambar 3. 4 LRS basis data administrasi sekolah
63
3.2.1.4 Normalisasi
Normalisasi diperlukan jika tabel-tabel yang dibuat belum normal. Karena
tabel-tabel yang dihasilkan dari transformasi ERD pada gambar 3.3 telah
memenuhi syarat normal ke-3 (3NF), maka tabel-tabel tersebut tidak perlu
dinormalisasi lagi.
3.2.1.5 Spesifikasi Basis Data
Spesifikasi basis data ditampilkan pada tabel-tabel berikut ini:
Tabel 3. 1 Tabel jenis persyaratan
No Nama Field Tipe Field Ukuran Indeks
1 kd_jpers Varchar 2 Primary
2 nm_jpers Varchar 30
3 stn_pers Varchar 10
4 jmlh_pers Int
Tabel 3. 2 Tabel jenis pembayaran
No Nama Field Tipe Field Ukuran Indeks
1 kd_jpem Varchar 5 Primary
2 nm_jpem Varchar 30
3 bsr_pem Int
4 bts_pem Date
Tabel 3. 3 Tabel persyaratan
No Nama Field Tipe Field Ukuran Indeks
1 kd_cs Varchar 9 Primary
2 kd-jpers Varchar 2 Primary
64
Tabel 3. 4 Tabel pembayaran
No Nama Field Tipe Field Ukuran Indeks
1 no_pem Varchar 12 Primary
2 nis Varchar 9
3 wkt_pem Datetime
4 no_peg Varchar 9
Tabel 3. 5 Tabel detil pembayaran
No Nama Field Tipe
Field
Ukuran Indeks
1 no_pem Varchar 12 Primary
3 kd_jpem Varchar 5 Primary
Tabel 3. 6 Tabel calon siswa
No Nama Field Tipe Field Ukuran Indeks
1 kd_cs Varchar 9 Primary
2 nm_cs Varchar 30
3 almt_cs Varchar 100
4 tmp_lhr_cs Varchar 40
5 tgl_lhr_cs Date
6 asl_sklh_cs Varchar 60
7 thn_lls_cs Smallint
8 nli_ujn_nsnl_cs Double
65
Tabel 3. 7 Tabel siswa
No Nama Field Tipe Field Ukuran Indeks
1 nis Varchar 9 Primary
2 nm_sis Varchar 30
3 almt_sis Varchar 100
4 tmp_lhr_sis Varchar 40
5 tgl_lhr_sis Date
6 asl_sklh_sis Varchar 60
7 thn_lls_sis Smallint
8 nli_ujn_nsnl_sis Double
9 thn_msk Smallint
Tabel 3. 8 Tabel staf administrasi
No Nama Field Tipe Field Ukuran Indeks
1 no_peg Varchar 9 Primary
2 nm_peg Varchar 30
3 almt_peg Varchar 120
4 tmp_lhr_peg Varchar 40
5 tgl_lhr_peg Date
6 pass_peg Varchar 32
Tabel 3. 9 Tabel guru
No Nama Field Tipe Field Ukuran Indeks
1 nig Varchar 9 Primary
2 nm_gru Varchar 30
3 almt_gru Varchar 120
4 tmpt_lhr_gru Varchar 40
5 tgl_lhr_gru Date
6 pass_gru Varchar 32
66
Tabel 3. 10 Tabel jurusan
No Nama Field Tipe Field Ukuran Indeks
1 kd_jrsn Varchar 2 Primary
2 nm_jrsn Varchar 30
Tabel 3. 11 Tabel kelas
No Nama Field Tipe Field Ukuran Indeks
1 kd_kls Varchar 9 Primary
2 nm_kls Varchar 15
3 kd_jrsn Varchar 2
4 dy_tmpng Tinyint
Tabel 3. 12 Tabel kelas siswa
No Nama Field Tipe Field Ukuran Indeks
1 nig Varchar 9 Primary
2 kd_kls Varchar 9 Primary
Tabel 3. 13 Tabel kelompok mata pelajaran
No Nama Field Tipe Field Ukuran Indeks
1 kd_klmpk_matpel Varchar 1 Primary
2 nm_klmpk_matpel Varchar 25
67
Tabel 3. 14 Tabel mata pelajaran
No Nama Field Tipe Field Ukuran Indeks
1 kd_matpel Varchar 5 Primary
2 nm_matpel Varchar 25
3 kd_klmpk_matpel Varchar 1
4 nli_kkm Double
Tabel 3. 15 Tabel jadwal
No Nama Field Tipe Field Ukuran Indeks
1 kd_jdwl Varchar 5 Primary
2 kd_kls Varchar 9
3 hri Tinyint
4 kd_jm Varchar 2
5 kd_matpel Varchar 5
6 nig Varchar 9
Tabel 3. 16 Tabel jam
No Nama Field Tipe Field Ukuran Indeks
1 kd_jm Varchar 2 Primary
2 ktrngn Varchar 15
3 mlai Time
4 slsai Time
68
Tabel 3. 17 Tabel nilai
No Nama Field Tipe Field Ukuran Indeks
1 kd_matpel_nli Varchar 5 Primary
2 nis Varchar 9 Primary
3 tgs Double
4 ulngn Double
5 uts Double
6 uas Double
3.2.2 Perancangan Aplikasi
3.2.2.1 Use Case Diagram
Aplikasi administrasi yang akan dibuat dirancang menggunakan use case
diagram seperti pada gambar 3.4. Use diagram yang dibuat menggunakan
package diagram karena jumlah use case-nya terlalu banyak. Jika tidak
menggunakan package diagram, relasi (hubungan) antara use case dengan actor
maupun antara use case dengan use case lain akan banyak yang bersilangan, hal
ini akan sulit dibaca/dipelajari. Pada gambar (diagram) selanjutnya akan
digambarkan detil masing-masing package.
69
Gambar 3. 5 Use case diagram aplikasi administrasi sekolah
70
Gambar 3. 6 Paket use case diagram akses aplikasi
Gambar 3. 7 Paket use case diagram master data
uc Akses Aplikasi
Guru
(from Use Case Model)
Staf
(from Use Case Model)
Login
Logout
uc Master Data
Staf
(from Use Case Model)
Mengelola Jenis
Persyaratan
Mengelola Jenis
Pembayaran
Mengelola Data
Mata Pelajaran
Mengelola Data
Kelas
Mengelola Data
Guru
Mengelola Data
Staf Administrasi Mengelola Data
Siswa
Mengelola Data Jam
Mengelola Data
Jurusan
Mengelola Data
Kelas Siswa
Mengelola Data
Kelompok Mata
Pelajaran
71
Gambar 3. 8 Paket use case diagram transaksi
Gambar 3. 9 Paket use case diagram laporan
uc Transaksi
Staf
(from Use Case Model)
Guru
(from Use Case Model)
Mengelola Data
Pendaftaran
Mengelola Data
Pembayaran
Mengelola Data Nilai
Mengelola Jadwal
Memproses
Penerimaan Siswa
uc Laporan
Guru
(from Use Case Model)
Staf
(from Use Case Model)
Mencetak Laporan
Penerimaan Siswa
Mencetak Laporan
Pembayaran
Mencetak Jadwal
Mencetak Nilai
72
3.2.2.2 Sequence Diagram
Setelah dibuat use case diagram, selanjutnya masing-masing use case
dibuatkan sequence diagram-nya sebagai berikut:
A. Sequence diagram login
Gambar 3. 10 Sequence diagram login
B. Sequence diagram logout
Gambar 3. 11 Sequence diagram logout
sd Interaction
Staf
(from Use Case Model)
Guru
(from Use Case Model)
FormLogin LoginController Staf Guru
inputUserId()
inputPassword()
klikLoginButton()
inputNig()
inputPassword()
klikLoginButton()
prosesLogin()
baca(userId, password) :boolean
baca(nig, password) :boolean
sd Interaction
Guru
(from Use Case Model)
Staf
(from Use Case Model)
FormUtama LogoutController
klikLogoutButton()
klikLogoutButton()
prosesLogout()
73
C. Sequence diagram mengelola jenis persyaratan
Gambar 3. 12 Sequence diagram mengelola jenis persyaratan
D. Sequence diagram mengelola jenis pembayaran
Gambar 3. 13 Sequence diagram mengelola jenis pembayaran
sd Interaction
Staf
(from Use Case Model)
FormJenisPersyaratan JenisPersyaratanController JenisPersyaratanFormDaftarJenisPersyaratan
inputKodePersyaratan()
inputDataPersyaratan()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus()
hapus(kodeJenisPersyaratan)
klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()
sd Interaction
FormJenisPembayaran JenisPembayaranController JenisPembayaranStaf
(from Use Case Model)
FormDaftarJenisPembayaran
inputKodePembayaran()
inputDataPembayaran()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(kodeJenisPembayaran)
hapus(kodeJenisPembayaran)
klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()
74
E. Sequence diagram mengelola data staf administrasi
Gambar 3. 14 Sequence diagram mengelola data staf administrasi
F. Sequence diagram mengelola data guru
Gambar 3. 15 Sequence diagram mengelola data guru
sd Interaction
FormStafAdministrasi StafAdministrasiController StafAdministrasiFormDaftarStafAdministrasiStaf
(from Use Case Model)
inputNoPegawai()
inputDataPegawai()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(noPegawai)
hapus(noPegawai)
klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()
sd Interaction
FormGuru GuruController GuruFormDaftarGuruStaf
(from Use Case Model)
Guru
(from Use Case Model)
inputNig()
inputNig()
inpuDataGuru()
inputDataGuru()
klikSimpanButton()
klikSimpanButton()
simpan()simpan()
klikHapusButton()
klikHapusButton()
hapus(nig)hapus(nig)
klikDaftarButton()
klikDaftarButton()
tampilkanDaftar()
bacaData()tampilkanData()
75
G. Sequence diagram mengelola data siswa
Gambar 3. 16 Sequence diagram mengelola data siswa
H. Sequence diagram mengelola kelompok mata pelajaran
Gambar 3. 17 Sequence diagram mengelola kelompok mata pelajaran
sd Interaction
FormSiswa SiswaController SiswaFormDaftarSiswaStaf
(from Use Case Model)
inputNis()
inputDataSiswa()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
haspu(nis)
hapus(nis)
klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()
sd Interaction
FormKelompokMataKuliah KelompokMataKuliahController KelompokMataKuliahFormDaftarKelompokMataKuliahStaf
(from Use Case Model)
inputKodeKelompokMataKuliah()
inputDataKelompokMataKuliah()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(kodeKelompokMataKuliah)
hapus(kodeKelompokMataKuliah)
klikDaftarButton()
tampilkanDaftar()bacaData()
tampilkanData()
76
I. Sequence diagram mengelola mata pelajaran
Gambar 3. 18 Sequence diagram mengelola mata pelajaran
J. Sequence diagram mengelola data jam
Gambar 3. 19 Sequence diagram mengelola data jam
sd Interaction
FormMataPelajaran MataPelajaranController MataPelajaranFormDaftarMataPelajaranStaf
(from Use Case Model)
inputKodeMataPelajaran()
inputDataMataPelajaran()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(kodeMataPelajaran)
hapus(kodeMataPelejaran)
klikDaftarButton()
tampilkanDaftar()
bacaData()tampilkanData()
sd Interaction
FormJam JamController JamFormDaftarJamStaf
(from Use Case Model)
inputKodeJam()
inputDataJam()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(kodeJam)
hapus(kodeJam)
klikDaftarButton()
tampilkanDaftarJam()
bacaData()
tampilkanData()
77
K. Sequence diagram mengelola data jurusan
Gambar 3. 20 Sequence diagram mengelola data jurusan
L. Sequence diagram mengelola data kelas
Gambar 3. 21 Sequence diagram mengelola data kelas
sd Interaction
FormJurusan JurusanController JurusanFormDaftarJurusanStaf
(from Use Case Model)
inputKodeJurusan()
inputDataJurusan()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(kodeJurusan)
hapus(kodeJurusan)
klikDaftarButton()
tampilkanDaftar()
bacaData()tampilkanData()
sd Interaction
FormKelas KelasController KelasFormDaftarKelasStaf
(from Use Case Model)
inputDataKelas()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus()
hapus()
klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()
78
M. Sequence diagram mengelola data kelas siswa
Gambar 3. 22 Sequence diagram mengelola data kelas siswa
N. Sequence diagram mengelola data pendaftaran
Gambar 3. 23 Sequence diagram mengelola data pendaftaran
sd Interaction
FormKelasSiswa KelasSiswaController KelasSiswaFormDaftarKelasSiswaStaf
(from Use Case Model)
inputDataKelasSiswa()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus()
hapus()
klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()
sd Interaction
Staf
(from Use Case Model)
FormPendaftaran PendaftaranController CalonSiswa
inputNoPendaftaran()
inputDataCalonSiswa()
inputKelengkapanPersyaratan()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus()
hapus()
klikDaftarButton()
tampilkanDaftarCalonSiswa()
bacaData()
tampilkanData()
79
O. Sequence diagram diagram proses penerimaan siswa
Gambar 3. 24 Sequence diagram diagram proses penerimaan siswa
P. Sequence diagram mengelola data pembayaran
Gambar 3. 25 Sequence diagram mengelola data pembayaran
sd Interaction
Staf
(from Use Case Model)
FormPenerimaanSiswa PenerimaanSiswaController CalonSiswa Siswa KelasSiswa
inputTahunAjaran()
hitungJumlahCalonSiswa()
bacaData()
setJumlahCalonSiswa()
klikProsesPenerimaanSiswaButton()
prosesPenerimaanSiswa()
bacaData()
setJumlahDiterima()
klikSimpanButton()
simpan()
bacaData()
simpan()
simpan()
sd Interaction
Staf
(from Use Case Model)
FormPembayaran PembayaranController JenisPembayaran Pembayaran DetilPembayaran
inputNoPembayaran()
klikBaruButton()
noPembayaranBaru()
bacaNoPembayaranTerakhir()
setNoPembayaran()
inputDataPembayaran()
tampilkanDataPembayaran()
baca()
setNamaPembayaran()
setBesarPembayaran()
klikSimpanButton()
simpan()
simpan()
simpan()
klikHapusButton()
hapus(noPembayaran)
hapus(noPembayaran)
hapus(noPembayaran)
klikDaftarButton()
tampilkanDaftarPembayaran()
bacaData()
tampilkanData()
80
Q. Sequence diagram mengelola jadwal
Gambar 3. 26 Sequence diagram mengelola jadwal
sd Interaction
Staf
(from Use Case Model)
FormJadwal JadwalController Jadwal Kelas MataPelajaran Guru JamFormDaftarJadwal
bukaForm()
aturTampilanAwal()
bacaData()
setItemKelasComboBox()
bacaData()
setItemMataPelajaranComboBox()
bacaData()
setItemGuruComboBox()
bacaData()
setItemJamComboBox()
inputKodeJadwal()
cari(kodeJadwal)
baca(kodeJadwal)
tampilkanDataJadwal()
klikDaftarButton()
tampilkanDaftarJadwal()
bacaData()
tampilkanData()
klikPilihButton()
tampilkanDataJadwal()
baca(kodeDipil ih)
tampilkanDataJadwal()
klikSimpanButton()
simpan()
simpan()
klikHapusButton()
hapus(kodeJadwal)
hapus(kodeJadwal)
81
R. Sequence diagram mengelola data nilai
Gambar 3. 27 Sequence diagram mengelola data nilai
sd Interaction
Guru
(from Use Case Model)
FormNilai NilaiController Nilai Jadwal KelasSiswa MataPelajaran SiswaFormDaftarJadwal
inputKodeJadwal()
cariDataJadwal()
baca()
tampilkanDataJadwal()
baca()
tampilkanDataKelasSiswa()
baca()
tampilkanNamaMataPelajaran()
baca()
tampilkanDataSiswa()
baca()
tampilkanNilaiSiswa()
klikDaftarButton()
tampilkanDaftarJadwal()
bacaData()
tampilkanData()
klikPilihButton()
tampilkanDataJadwal()
baca()
tampilkanDataKelasSiswa()
baca()
tampilkanNamaMataPelajaran()
baca()
tampilkanDataSiswa()
baca()
tampilkanNilaiSiswa()
inputDataNilai()
klikSimpanButton()
simpan()
simpan()
82
S. Sequence diagram mencetak laporan penerimaan siswa
Gambar 3. 28 Sequence diagram mencetak laporan penerimaan siswa
T. Sequence diagram mencetak laporan pembayaran
Gambar 3. 29 Sequence diagram mencetak laporan pembayaran
sd Interaction
Staf
(from Use Case Model)
FormLaporanPenerimaanSiswa PenerimaanSiswaController Siswa
inputTahunAjaran()
klikCetakButton()
cetakPenerimaanSiswa(tahunAjaran)
cetakSiswaBaru(tahunAjaran)
sd Interaction
FormLaporanPembayaran Pembayaran SiswaStaf
(from Use Case Model)
klikCetakButton()
cetakPembayaran()
cetak()
83
U. Sequence diagram mencetak laporan nilai
Gambar 3. 30 Sequence diagram mencetak laporan nilai
V. Sequence diagram mencetak laporan jadwal
Gambar 3. 31 Sequence diagram mencetak laporan jadwal
3.2.2.3 Activity Diagram
Masing-masing use case juga dibuatkan activity diagram untuk
menunjukkan alur prosesnya.
sd Interaction
Guru
(from Use Case Model)
Staf
(from Use Case Model)
FormLaporanNilai NilaiNilaiController
klikCetakButton()
cetakNilai()
cetak()
klikCetakButton()
cetakNilai()
cetak()
sd Interaction
Guru
(from Use Case Model)
Staf
(from Use Case Model)
FormLaporanJadwal JadwalController Jadwal
klikCetakButton()
cetakJadwal()
cetak()
klikCetakButton()
cetakJadwal()
cetak()
84
A. Activity diagram login
Gambar 3. 32 Activity diagram login
B. Activity diagram logout
Gambar 3. 33 Activity diagram logout
act Activ ity
Mulai
Input User ID (atau NIG)
dan password
valid?
Masuk ke dalam
sistem/aplikasi dan aktifkan
menu sesuai hak aksesnya
Selesai
[Tidak]
[Ya]
act Activ ity
Mulai
Klik tombol Logout
Disable semua menu
Selesai
85
C. Activity diagram mengelola jenis persyaratan
Gambar 3. 34 Activity diagram mengelola jenis persyaratan
act Activ ity
Mulai
Selesai
Input kode jenis persyaratan, nama
persyaratan, jumlah, dan satuan
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar jenis
persyaratan
Ada yang
dipil ih?
Simpan data (update/insert)
jenis persyaratan
Hapus data jenis
persyaratan
Tampilkan data jenis
persyaratan yang dipilih
[Tidak]
[Ya]
86
D. Activity diagram mengelola jenis pembayaran
Gambar 3. 35 Activity diagram mengelola jenis pembayaran
act Activ ity
Mulai
Selesai
Input kode jenis pembayaran, nama
pembayaran, jangka, dan satuan
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar jenis
pembayaran
Ada yang dipil ih?
Simpan data (update/insert)
jenis pembayaran
Hapus data jenis
pembayaran
Tampilkan data jenis
pembayaran yang dipilih
[Ya]
[Tidak]
87
E. Activity diagram mengelola data staf administrasi
Gambar 3. 36 Activity diagram mengelola data staf administrasi
act Activ ity
Mulai
Selesai
Input no. pegawai, nama, alamat,
tempat lahir, tanggal lahir, dan
password
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar staf
administrasi
Ada yang
dipil ih?
Simpan data (update/insert)
staf administrasiHapus data staf
administrasi
Tampilkan data staf
administrasi yang dipilih
[Ya]
[Tidak]
88
F. Activity diagram mengelola data guru
Gambar 3. 37 Activity diagram mengelola data guru
act Activ ity
Mulai
Selesai
Input NIG, nama, alamat, tempat
lahir, tanggal lahir, dan password
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar guru
Ada yang
dipil ih?
Simpan data (update/insert)
guru
Hapus data guru
Tampilkan data guru yang
dipilih
[Ya]
[Tidak]
89
G. Activity diagram mengelola data siswa
Gambar 3. 38 Activity diagram mengelola data siswa
act Activ ity
Mulai
Selesai
Input no. pegawai, nama, alamat, tempat
lahir, tanggal lahir, asal sekolah, tahun
lulus, dan nilai uj ian nasional
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar siswa
Ada yang
dipil ih?
Simpan data (update/insert)
siswa
Hapus data siswa
Tampilkan data siswa
yang dipilih
[Tidak]
[Ya]
90
H. Activity diagram mengelola kelompok mata pelajaran
Gambar 3. 39 Activity diagram mengelola kelompok mata pelajaran
act Activ ity
Mulai
Selesai
Input kode kelompok, dan nama
kelompok
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar
kelompok mata pelajaran
Ada yang dipil ih?
Simpan (update/insert) data
kelompok mata pelajaran
Hapus data kelompok
mata pelajaran
Tampilkan data kelompok
mata pelajaran yang dipilih
[Ya]
[Tidak]
91
I. Activity diagram mengelola mata pelajaran
Gambar 3. 40 Activity diagram mengelola mata pelajaran
act Activ ity
Mulai
Selesai
Input kode mata pelajaran, dan nama
mata pelajaran
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar mata
pelajaran
Ada yang
dipil ih?
Simpan data (update/insert)
mata pelajaran
Hapus data mata
pelajaran
Tampilkan data mata
pelajaran yang dipilih
[Tidak]
[Ya]
92
J. Activity diagram mengelola data jam
Gambar 3. 41 Activity diagram mengelola data jam
act Activ ity
Mulai
Selesai
Input kode jam, keterangan, mulai,
dan selesai
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar jam
Ada yang dipil ih?
Simpan (update/insert) data
jam
Hapus data jam
Tampilkan data jam yang
dipilih
[Tidak]
[Ya]
93
K. Activity diagram mengelola data jurusan
Gambar 3. 42 Activity diagram mengelola data jurusan
act Activ ity
Mulai
Selesai
Input kode jurusan, dan nama
jurusan
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar jurusan
Ada yang dipil ih?
Simpan (update/insert) data
jurusan
Hapus data jurusan
Tampilkan data jurusan
yang dipilih
[Ya]
[Tidak]
94
L. Activity diagram mengelola data kelas
Gambar 3. 43 Activity diagram mengelola data kelas
act Activ ity
Mulai
Selesai
Input tahun ajaran, semester, tingkat,
kode jurusan, urutan kelas, dan daya
tampung
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar kelas
Ada yang
dipil ih?
Simpan (update/insert) data
kelas
Hapus data kelas
Tampilkan data kelas yang
dipilih
[Ya]
[Tidak]
95
M. Activity diagram mengelola data kelas siswa
Gambar 3. 44 Activity diagram mengelola data kelas siswa
act Activ ity
Mulai
Selesai
Input tahun ajaran, semester, tingkat,
kode jurusan, urutan kelas, dan nis
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar kelas
siswa
Ada yang
dipil ih?
Simpan (update/insert) data
kelas siswaHapus data kelas siswa
Tampilkan data kelas siswa
yang dipilih
[Ya]
[Tidak]
96
N. Activity diagram mengelola data pendaftaran
Gambar 3. 45 Activity diagram mengelola data pendaftaran
act Activ ity
Mulai
Selesai
Input tahun ajaran, no. pendaftaran,
data siswa, dan data kelengkapan
persyaratan
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar calon
siswa
Ada yang
dipil ih?
Simpan (update/insert) data
calon siswa
Hapus data calon siswa
Tampilkan data calon
siswa yang dipilih
klik tombol no.
pendaftaran baru
tampilkan no. pendaftaran
baru[Tidak]
[Ya]
97
O. Activity diagram proses penerimaan siswa
Gambar 3. 46 Activity diagram proses penerimaan siswa
act Activ ity
Mulai
Selesai
Tampilkan jumlah calon siswa,
dan daya tampung
Klik tombol proses
penerimaanKlik tombol simpan
Urutkan calon siswa berdasarkan
jurusan yang dipilih, nilai uj ian
nasional (desc), tahun lulus (desc),
dan no pendaftaran. Simpan semua data calon
siswa yang telah
dialokasikan ke dalam
tabel siswa
Alokasikan calon siswa dalam
kelas sesuai daya tampung
98
P. Activity diagram mengelola data pembayaran
Gambar 3. 47 Activity diagram mengelola data pembayaran
act Activ ity
Mulai
Selesai
Input no. pembayaran, data siswa,
dan data pembayaran
Klik tombol simpan Klik tombol hapus
Klik tombol daftar
Tampilkan daftar
pembayaran
Ada yang
dipil ih?
Simpan (update/insert) data
pembayaran
Hapus data pembayaran
Tampilkan data
pembayaran yang dipilih
klik tombol no.
pembayaran baru
tampilkan no. pembayaran
baru
[Ya]
[Tidak]
99
Q. Activity diagram mengelola jadwal
Gambar 3. 48 Activity diagram mengelola jadwal
act Activ ity
Mulai
Selesai
Input data nilai
Klik tombol simpan
Klik tombol daftar
Ada yang
dipil ih?Simpan data nilai
Tampilkan data jadwal
yang dipilih
Input kode Jadwal
Tampilkan data siswa
dan nilainya
Tampilkan daftar jadwal
[Ya]
[Tidak]
100
R. Activity diagram mengelola data nilai
Gambar 3. 49 Activity diagram mengelola data nilai
act Activ ity
Mulai
Selesai
Input nilai siswa
Klik tombol simpan
Klik tombol daftar
Tampilkan daftar jadwal
Ada yang
dipil ih?
Simpan data nilai siswa
Tampilkan data siswa
sesuai jadwal yang dipilih
[Tidak]
[Ya]
101
S. Activity diagram mencetak laporan penerimaan siswa
Gambar 3. 50 Activity diagram mencetak laporan penerimaan siswa
act Activ ity
Mulai
Input tahun ajaran
Tombol cetak diklik Tombol tutup diklik
Cetak data penerimaan siswa
sesuai tahun ajaran yang diinput
Selesai
Tutup form
102
T. Activity diagram mencetak laporan pembayaran
Gambar 3. 51 Activity diagram mencetak laporan pembayaran
act Activ ity
Mulai
Tampilkan pilihan data
pembayaran yang akan dicetak
Tombol cetak diklik Tombol tutup diklik
Cetak data pembayaran
Selesai
Tutup form
103
U. Activity diagram mencetak laporan nilai
Gambar 3. 52 Activity diagram mencetak laporan nilai
act Activ ity
Mulai
Tampilkan pilihan Nilai
yang akan dicetak
Tombol cetak diklik Tombol tutup diklik
Cetak nilai
Selesai
Tutup form
104
V. Activity diagram mencetak laporan jadwal
Gambar 3. 53 Activity diagram mencetak laporan jadwal
act Activ ity
Mulai
Tampilkan pilihan jadwal
yang akan dicetak
Tombol cetak diklik Tombol tutup diklik
Cetak data jadwal
Selesai
Tutup form
105
3.2.2.4 Class Diagram
Rancangan hubungan antar-class dibuat dalam diagram class sebagai
berikut:
Gambar 3. 54 Class diagram aplikasi administrasi sekolah
106
3.2.2.5 User Interface (Antarmuka Pengguna)
Antarmuka pengguna dibuat seperti gambar-gambar di bawah ini:
A. Desain antarmuka form utama
Gambar 3. 55 Desain antarmuka form utama
B. Desain antarmuka form login
Gambar 3. 56 Desain antarmuka form login
custom Aplikasi
Form Login
User ID
Password
Status Staf Administrasi
Login Batal
107
C. Desain antarmuka informasi aplikasi
Gambar 3. 57 Desain antarmuka informasi aplikasi
D. Desain antarmuka master data jenis persyaratan
Gambar 3. 58 Desain antarmuka master data jenis persyaratan
custom Aplikasi
Informasi Aplikasi
Aplikasi Administrasi Sekolah
SMK AVERUS JAKARTA
Oleh: Yulianti
NIM: 2009140661
Universitas Pamulang 2013
custom Master Data
Master Data Jenis Persyaratan
Kode Persyaratan Daftar
Nama Persyaratan
Satuan
Jumlah
Simpan Hapus Tutup
108
E. Desain antarmuka master data jenis pembayaran
Gambar 3. 59 Desain antarmuka master data jenis pembayaran
custom Master Data
Master Data Jenis Pembayaran
Kode Jenis Pembayaran Daftar
Nama Jenis Pembayaran
Satuan
Jumlah Pembayaran
Simpan Hapus Tutup
Jangka Waktu
109
BAB IV
IMPLEMENTASI DAN PENGUJIAN
4.1 Implemantasi
4.1.1 Implementasi Basis Data
Rancangan basis data diimplementasikan pada DBMS (Database
Management System) MySQL dan dihasilkan diagram relasi sebagai berikut:
110
Gambar 4. 1 Diagram relasi basis data administrasi sekolah
111
4.1.2 Implementasi Aplikasi
Rancangan yang telah dibuat pada bab III diimplementasikan menggunakan
bahasa pemrograman Java menggunakan IDE (Integrated Development
Environment) NetBeans, sehingga dihasilkan seperti berikut ini:
A. Tampilan form deskripsi
Gambar 4. 2 Tampilan form deskripsi
B. Tampilan form login
Gambar 4. 3 Tampilan form login
112
C. Tampilan form utama
Gambar 4. 4 Tampilan form utama
D. Tampilan form siswa
Gambar 4. 5 Tampilan form siswa
113
E. Tampilan form guru
Gambar 4. 6 Tampilan form guru
F. Tampilan form staf administrasi
Gambar 4. 7 Tampilan form staf administrasi
114
G. Tampilan form pendaftaran
Gambar 4. 8 Tampilan form pendaftaran
H. Tampilan form penerimaan siswa
Gambar 4. 9 Tampilan form penerimaan siswa
115
I. Tampilan form pembayaran
Gambar 4. 10 Tampilan form pembayaran
J. Tampilan form jadwal
Gambar 4. 11 Tampilan form jadwal
116
K. Tampilan form nilai
Gambar 4. 12 Tampilan form nilai
L. Tampilan form laporan penerimaan siswa
Gambar 4. 13 Tampilan form laporan penerimaan siswa
117
M. Tampilan form laporan nilai
Gambar 4. 14 Tampilan form laporan nilai
N. Tampilan form laporan pembayaran
Gambar 4. 15 Tampilan form laporan pembayaran
118
O. Tampilan form laporan jadwal
Gambar 4. 16 Tampilan form laporan jadwal
4.2 Pengujian
Pengujian telah dilakukan menggunakan metode black box dan white box
selama pengembangan aplikasi, pengujian dilakukan untuk memastikan bahwa
rancangan algoritma dan implementasi pada source code program telah sesuai
dengan tujuan yang telah ditentukan. Pengujian telah dilakukan baik per blok
source code program maupun per modul. Bug (cacat) yang ditemukan pada
aplikasi langsung diperbaiki agar sesuai dengan proses yang diinginkan.
4.2.1 Pengujian Black Box
Pengujian black box dilakukan dengan menguji fungsionalitas (functional
testing) aplikasi. Pengujian dilakukan dengan mengecek fungsionalitas pada
bagian tertentu sesuai tabel berikut ini:
119
Tabel 4. 1 Pengujian fungsionalitas (functional testing)
No
.
Skenario pengujian Test case Hasil yang
diharapkan
Hasil
pengujian
Kesimpulan
1 Memilih (mengklik)
menu login
Klik menu item
login
Menampilkan
form login
Sesuai
harapan
valid
2 Mengosongkan form
login, kemudian
mengklik button
login
Jabatan dipilih
staf
administrasi, no.
pegawai kosong,
password
kosong
Menampilkan
keterangan
no. pegawai
harus diisi
Sesuai
harapan
valid
3 Melakukan login
dengan memilih
jabatan staf dengan
data yang benar
Jabatan dipilih
staf
administrasi, no.
pegawai diisi
ADMIN, dan
password diisi
ADMIN
Berhasil login
dan menu
untuk staf
administrasi
diaktifkan
Sesuai
harapan
valid
4 Mengosongkan kode
persyaratan pada
form master data
jenis persyaratan,
kemudian mengklik
tombol simpan
Kode
persyaratan = ””
Aplikasi
menampilkan
pesan “Kode
persyaratan
tidak boleh
kosong”
Sesuai
harapan
Valid
5 Mengosongkan kode
persyaratan pada
form master data
jenis persyaratan,
kemudian mengklik
tombol hapus
Kode
persyaratan = ””
Aplikasi
menampilkan
pesan “Kode
persyaratan
tidak boleh
kosong”
Sesuai
harapan
Valid
120
4.2.2 Pengujian White Box
Pengujian white box dilakukan dengan menguji unit (unit testing) untuk
memastikan bahwa modul/unit dapat bekerja sesuai harapan. Pengujian dilakukan
menggunakan fasilitas yang tersedia pada IDE NetBeans sebagai berikut:
A. Membuat test (pengujian)
Gambar 4. 17 Membuat test (pengujian) unit (white box)
121
B. Menentukan test (pengujian)
Gambar 4. 18 Menentukan test (pengujian) unit (white box)
C. Mengubah kondisi test (pengujian)
@Test
public void testGetKodePersyaratan() {
System.out.println("getKodePersyaratan");
JenisPersyaratan instance = new JenisPersyaratan();
String expResult = null;
String result = instance.getKodePersyaratan();
assertEquals(expResult, result);
// TODO review the generated test code and remove
the default call to fail.
//fail("The test case is a prototype.");
}
Variabel expResult diisi dengan nilai yang diharapkan setelah metode
diproses, sedangkan variabel result adalah nilai setelah metode diproses.
Jika kedua variabel bernilai sama, maka dianggap metodenya benar
(sesuai yang diharapkan).
122
D. Melakukan test (pengujian)
Gambar 4. 19 Melakukan test (pengujian) unit (white box)
E. Menampilkan hasil test (pengujian)
Jika hasil pengujian tidak menampilkan kesalahan seperti pada gambar
4.20 di bawah ini berarti unit/metode yang diuji tidak ada kesalahan.
Gambar 4. 20 Hasil test (pengujian) unit (white box)
123
Berikut ini hasil test (pengujian) untuk empat unit/modul:
Gambar 4. 21 Hasil test (pengujian) empat unit/modul unit (white box)
4.3 Analisa
Setelah aplikasi yang dibuat diimplementasikan pada jaringan LAN (Local
Area Network) menggunakan satu server basis data, yaitu MySQL, aplikasi dapat
digunakan secara bersamaan, dapat yang tersimpan dapat digunakan secara
bersamaan, sehingga ketika meng-input data dapat lebih cepat.
Aplikasi yang telah dibuat menggunakan arsitektur MVC (Model-View-
Controller) dapat memperpendek source code program, karena beberapa modul
(metode atau class) dapat digunakan modul lain tanpa mengetik ulang. Misalnya,
jika tidak menggunakan arsitektur MVC, maka source code untuk membaca atau
menampilkan data siswa harus diketik di modul form siswa dan modul form
pembayaran. Tetapi jika menggunakan arsitektur MVC, maka source code
124
tersebut cukup diketik di satu modul, kemudian modul lain tinggal memanggil
nama metodenya.
Jika menggunakan arsitektur MVC, ketika melakukan perubahan source
code pada modul user interface (antarmuka pengguna) tidak harus mengubah
bagian model (modul yang berhubungan dengan database). Hal ini dapat
mempermudah untuk menyesuaikan dengan kebutuhan di masa depan.
125
BAB V
PENUTUP
5.1 Kesimpulan
Dari hasil implementasi dan analisa pada bab sebelumnya, dapat diambil
kesimpulan sebagai berikut:
a. Aplikasi administrasi sekolah yang dibangun dengan arsitektur client-
server dapat mengurangi duplikasi data, karena semua data disimpan
dalam basis data yang terpusat dan digunakan dengan sistem berbagi.
b. Aplikasi administrasi sekolah yang telah dibuat dapat memperbaiki
pengorganisasian dokumen-dokumen di sekolah, semua data disimpan
dalam basis data terpusat, data/dokumen yang diperlukan dapat dilihat,
dan dianalisa tanpa harus dicetak.
c. Aplikasi administrasi sekolah dapat mempercepat pembuatan laporan-
laporan yang diperlukan dari data-data administrasi, karena untuk
membuat laporan, tinggal memilih menu laporan yang diinginkan, dan
spesifikasi laporan yang akan dicetak.
d. Aplikasi yang dibuat dengan arsitektur MVC (Model-View-Controller)
menjadi lebih rapi, dapat memperpendek source code aplikasi, dan
mudah disesuaikan dengan kebutuhan di masa depan. Jika ada
perubahan pada tampilan antarmuka, maka tidak perlu mengubah source
code yang berhubungan dengan basis data.
5.2 Saran
Aplikasi administrasi sekolah yang telah dibuat hanya mencakup
administrasi pendaftaran, pembayaran, jadwal, dan nilai. Agar aplikasi lebih baik
dan lengkap, dapat dikembangkan lebih lanjut, yaitu:
a. Ditambahkan administrasi absensi siswa, kegiatan ekstrakulikuler.
b. Ditambahkan data-data siswa seperti, data kontak, hobi, data orangtua,
dan data wali murid.
c. Meningkatkan keamanan data dengan menggunakan arsitektur multitier.
126
DAFTAR PUSTAKA
Alam, M. A. (2005). Belajar Sendiri Pemrograman Database Lokal dan Server.
Jakarta: Elex Media Komputindo.
Antonio, H., & Safriadi, N. (2012). Rancang Bangun Sistem Informasi
Administrasi Informatika. Jurnal ELKHA, 12-14.
Booch, G. (1994). Object-Oriented Analysis and Design (Second ed.). California:
Addison Wesley.
Davis, W. S., & Yen, D. C. (1998). The Information System Consultant's
Handbook: Systems Analysis and Design. CRC Press.
Dennis, A., Wixom, B. H., & Roth, R. M. (2009). System Analysis and Design
(Fourth ed.). New Jersey: Wiley.
Depdiknas. (2013, 05 24). Kamus Besar Bahasa Indonesia. Diambil kembali dari
Departemen Pendidikan Nasional:
http://pusatbahasa.kemdiknas.go.id/kbbi/
Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object
Modeling Language (Third Edition). Boston: Addison-Wesley
Professional.
Gomaa, H. (2011). Software Modeling and Design. New York: Cambridge.
Hariyanto, B. (2007). Esensi-esensi Bahasa Pemrograman Java. Bandung:
Informatika Bandung.
Harrington, J. L. (2009). Relational database design and implementation: clearly
explained (3rd ed.). Burlington: Morgan Kaufmann.
Huda, M., & Komputer, B. (2009). Membuat Aplikasi Rental dengan Java dan
MySQL. Jakarta: Elex Media Komputindo.
Kadir, A. (2009). Dasar Perancangan dan Implementasi Database Relasional.
Yogyakarta: Andi.
Kristanti, T., & Redita, N. G. (2012). Sistem Informasi Nilai SMPN 14 Bandung.
Jurnal Sistem Informasi, 85-94.
127
Martha, D., Harianto, C., & Asfi, M. (2010). Metode MVC untuk Perancangan
Sistem Berorientasi Objek pada Ujian Saringan Masuk Penerimaan
Mahasiswa Baru di STMIK CIC Cirebon. Jurnal Informatika, 145 - 160.
Munawar. (2005). Pemodelan Visual Dengan UML. Yogyakarta: Graha Ilmu.
Nugroho, A. (2009). Rekayasa Perangkat Lunak Menggunakan UML dan Java.
Yogyakarta: Andi.
O’Regan, G. (2011). Introduction to Software Process Improvement. London:
Springer.
Prasetyo, D. D. (2004). Belajar Sendiri Aplikasi Database Client/Server
Menggunakan Delphi dan MySQL. Jakarta: Elex Media Komputindo.
Qureshi, M. R., & Sabir, F. (2013). A Comparison of Model View Controller and
Model View Presenter. The Science International (Lahore), 7-9.
Simarmata, J. (2010). Rekayasa Perangkat Lunak. Yogyakarta: Andi.
Stephens, R. (2009). Beginning Database Design Solutions. Indianapolis: Wiley.
Stephens, R. K., & Plew, R. R. (2001). Database Design. Indianapolis: Sams.
Sulindawaty, & Calam, A. (2011). Sistem Informasi Pengolahan Nilai Siswa Pada
SMP Swasta Bakti Medan. Jurnal SAINTIKOM, 53-69.
Sumarta, T., Siswoyo, B., & Juhana, N. (2004). Perancangan Model Berorientasi
Objek Menggunakan Unified Modeling Language (UML).
JBPTUNIKOMPP, 1-8.
Supriyanto. (2010). Pemrograman Database Menggunakan Java dan MySQL
untuk Pemula. Jakarta: Mediakita.
Utomo, E. P. (2009). Panduan Mudah Mengenal Bahasa Java. Bandung: Yrama
Widya.
Utpatadevi, N. L., Sudana, A. A., & Cahyawan, A. A. (2012). Implementation of
MVC (Model-View-Controller) Architectural to Academic Management
Information System with Android Platform Base. International Journal of
Computer Applications, 1-6.
'Uyun, S., & Ma'arif, M. R. (2010). Implementation of Model View Controller
(MVC) Architecture on Building Web-based Information System. Seminar
Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010), E-47 - E-50.
128
Vlugt, M. v., & Sambasivam, S. (2005). Redesign of Stand-Alone Applications
into Thin-Client/Server Architecture. Issues in Informing Science and
Information Technology, 723-742.
Wahana Komputer. (2010). Shortcourse SQL Server 2008 Express. Yogyakarta:
Andi.
Widhyaestoeti, D. (2011). Rancang Bangun Database Nilai Siswa Tingkat
Sekolah Menengah. Jurnal Ilmiah Teknologi dan Informasi Volume 2, 1-
18.
Widiyanto, N. (2010). Membangun Aplikasi Java Enterprise dengan Arsitektur
Model View Controller (MVC). Yogyakarta: Andi.
Wijono, G. S., Suharto, B. H., & Wijono, M. S. (2007). Pemrograman Java
Servlet dan JSP dengan NetBeans. Yogyakarta: Andi.
129
Lampiran 1 Formulir data pribadi calon siswa baru
130
131
Lampiran 2 Bidang keahlian bisnis dan manajemen SMK AVERUS
132
Lampiran 3 Jadwal mengajar SMK Averus
133
Lampiran 4 Kwitansi SMK AVERUS
134
Lampiran 5 Kartu tanda bukti pembayaran SMK AVERUS
135
136
Lampiran 6 Kartu hasil studi (KHS) SMK AVERUS
137
138
Lampiran 7 Kartu konsultasi mahasiswa
