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

ii
 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

iii
 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

iv
 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

v
 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)

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

vii
 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

viii
 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

ix
 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

x
 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

xi
 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

xii
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

xiii
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

xiv
 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

xv
 DAFTAR SIMBOL

No. Simbol Nama Simbol Keterangan

1 uc Use Case Model Boundary Untuk menggambarkan
Aplikasi
sistem atau aplikasi.

2 uc Use Ca...
Actor Untuk menggambarkan
pengguna (user)
Actor sistem/aplikasi

3 uc Use Case Model

Use Case Untuk menggambarkan apa
Use Case yang dilakukan actor
terhadap sistem
4 uc Use Case Model
Assosiation Garis lurus untuk
menunjukkan hubungan
actor dengan use case
uc Use Case Model
5 Generalization Garis dengan ujung
berbentuk panah,
menunjukan use case sumber
(source) adalah penjabaran
(detil) dari use case yang
ditunjuk panah (destination)
6 uc Use Case Model
Include Garis putus-putus dengan
«include»
ujung berbentuk panah,
menunjukan use case sumber
(source) akan selalu
dilakukan jika use case yang
ditunjuk panah (destination)
dilakukan

xvi
No. Simbol Nama Simbol Keterangan
7 uc Use Case Model
Package Digunakan untuk
Package
menggambarkan diagram
paket, yang berfungsi untuk
mengelompokkan use case
diagram atau class diagram
8 uc Use Case Model

Package
Trace Menggambarkan bahwa
«trace» sumber (source)
berhubungan dengan
sebagian/seluluh dalam
tujuan (destination)
9 class Class Model Class Untuk menggambarkan class
Class yang memiliki attribute dan
- attribute: int
method.
+ method() : void

uc Use Case Model

10 Package Package
Import Untuk menggambarkan
«import»

bahwa package sumber

(source) diimport oleh
anggota dari package tujuan
(destination)
11 act A... Initial Untuk menggambarkan awal
activity (aktivitas)

12 act A... Final Untuk menggambarkan akhir

activity (aktivitas)

13 act Activ ity

Activity Untuk menggambarkan
Activ ity
activity (aktivitas) yang
dilakukan

xvii
No. Simbol Nama Simbol Keterangan
14 act Activ ity Decission Untuk menggambarkan
percabangan activity
(aktivitas)
15 ac...
Fork/Join Untuk menunjukkan proses
act Activ ity
yang berjalan secara paralel

16 sd Interaction Boundary Untuk menggambarkan class

antarmuka (view) pada
Boundary
sequence diagram

17 sd Interaction Control Untuk menggambarkan class

proses (controller) pada
Control
sequence diagram

18 sd Interaction Entity Untuk menggambarkan class

entitas (model) pada
Entity
sequence diagram

xviii
 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

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

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

7
 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

Client

Network
Server

Client

Printer

Client

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

Class Diagram

Component
Diagram
Composite
Structure
Diagram

Structure Deployment
Diagram Diagram

Object Diagram

Package
Diagram
Diagram
Activity Diagram

Use Case
Diagram
Behavior
Diagram
State Machine
Diagram
Sequence
Diagram

Interaction Communication
Diagram 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
Menulis kode program
Kompilasi program Java
Menjalankan program Java
Tool Hasil
Text editor Berkas berekstensi .java
Compiler Berkas berekstensi .class
(Java Bytecodes)
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.
 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.

56
 57

Proses (aktivitas) dari sistem yang berjalan saat ini dapat digambarkan
dalam diagram activity (aktivitas) sebagai berikut:
act Business Process Model

Start

Guru mengolah dan

Calon sisw a melakukan
membuat rekap nilai
pendaftaran
sisw a

Sisw a melakukan Membuat j adw al

Calon sisw a mengisi form dan pembayaran belaj ar/mengaj ar
melengkapi persyaratan

Guru menetapkan
kelulusan sisw a
Data pembayaran dicatat
Calon sisw a menyerahkan
dalam buku j urnal
form pendaftaran dan
pembayaran
melengkapi persyaratan
Meng-input dan
mengolahnya
menggunakan Ms. Excel

Staf administrasi Data pembayaran direkap

mengecek formulir dan dan dimasukkan ke dalam
persyaratan buku besar
Guru menulis ke
dalam raport sisw a

Data sisw a di-input dan diolah Mencetak dan

menggunakan Ms. Excel untuk mengumumkan
Data pembayaran di-input dan
menetapkan calon sisw a yang diterima
diolah menggunakan Ms. Excel
untuk membuat laporan

Raport diberikan kepada

orang tua atau w ali sisw a
Calon sisw a yang diterima
diumumkan

Selesai

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

* kd_jpers
* kd _jpem * no_pem
* kd_cs Nm_jpers
nm _jpem * kd_jpem
* kd_jpers Stn_pers
bsr_pem
Jmlh_pers
Bts_pem
M
Memiliki Jenis Persyaratan M
Jenis Pembayaran terdiri

Calon Siswa
* no_pem
nis
M wkt_pem
* no_peg no_ peg M
* kd_cs nm_peg
nm_cs almt_peg
almt_cs Staf Administrasi Menerima Pembayaran
tmp_lhr_peg 1 M
tmp_lhr_cs tgl_lhr_peg
tgl_lhr_cs Pass_peg M
asl_sklh_cs * nis
thn_lls_cs nm_sis
nli_ujn_nsnl_cs almt_sis 1
Siswa Melakukan
tmp_lhr_sis
tgl_lhr_sis M M
asl_sklh_sis
thn_lls_sis
nli_ujn_nsnl_sisl
thn_msk_sis

Memilih
* nis
* nis Menempati * kd_mtpel
* kd_kls tgs
ulngn
uts
uas
1 M
* kd_kls
1 M
Jurusan Untuk Kelas nm_kls Mendapat
dy_tmpng
1
* kd_jrsn
Nm_jrsn
* nig
Menempati
nm_gru
almt_gru
tmp_lhr_gru
tgl_lhr_gru
pass_gru M
M M
Guru Mengajar Jadwal Untuk
1
1 M
M
* kd_jdwl
hri Mata Pelajaran
kd_jm
Jam Sesuai * kd_matpel M
kd_matpel
1 nig nm_matpel
* kd_jm kd_klmpk
ktrngn nli_kkm
mlai
slsai * kd_klmpk Kelompok Mata
Termasuk
Nm_klmpk Pelajaran
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:
* kd_jpers
* kd _jpem * no_pem
Nm_jpers
* kd_cs nm _jpem * kd_jpem
Stn_pers
* kd_jpers bsr_pem
Jmlh_pers
Bts_pem
M
Memiliki Jenis Persyaratan M
Jenis Pembayaran terdiri

Calon Siswa
* no_pem
nis
M wkt_pem
* kd_cs * no_peg no_ peg M
nm_cs nm_peg
almt_cs almt_peg
Staf Administrasi Menerima Pembayaran
tmp_lhr_cs tmp_lhr_peg 1 M
tgl_lhr_cs tgl_lhr_peg
asl_sklh_cs Pass_peg M
thn_lls_cs
* nis
nli_ujn_nsnl_cs
nm_sis 1
almt_sis Siswa Melakukan
tmp_lhr_sis
tgl_lhr_sis M M
asl_sklh_sis
thn_lls_sis
nli_ujn_nsnl_sisl
thn_msk_sis
Memilih * nis
* nis * kd_mtpel
Menempati
* kd_kls tgs
ulngn
uts
uas
1 M
1 M * kd_kls
Jurusan Untuk Kelas nm_kls Mendapat
dy_tmpng
1
* kd_jrsn
Nm_jrsn

Menempati

M
M M
Mengajar Jadwal Untuk
* nig
nm_gru 1 M
M
almt_gru * kd_jdwl
hri Mata Pelajaran
tmp_lhr_gru
tgl_lhr_gru kd_jm
Sesuai * kd_matpel M
pass_gru 1 kd_matpel
nig nm_matpel
Guru kd_klmpk
nli_kkm

Jam
1 Termasuk
* kd_jm
ktrngn 1
* kd_klmpk Kelompok Mata
mlai
Nm_klmpkl Pelajaran
slsai

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:
Jenis Persyaratan
Persyaratan Jenis Pembayaran
* kd_jpers
* kd_cs * kd_jpem
* kd_jpers Nm_jpers
* kd_jpers M 1 * nm_jpem
Stn_pers
stts Jmlh_pers
bsr_pem
bts_pem
M
M
* kd_cs Pembayaran * kd_jpem
1
* no_peg * no_pem
* nis * no_pem Detil Pembayaran
M
1 wkt_pem
1 M * no_pem
* no_peg
Calon Siswa 1 * kd_jpem
M
* kd_cs Staf Administrasi * nis
nm_cs
almt_cs * no_peg 1
tmp_lhr_cs nm_peg
tgl_lhr_cs almt_peg
Siswa
asl_sklh_cs tmp_lhr_peg
Kelas Siswa
1 M * nis
thn_lls_cs tgl_lhr_peg
* nis nm_sis
nli_ujn_nsnl_cs Pass_peg * nis
* kd_kls almt_sis
* kd_jrsn
tmp_lhr_sis
M tgl_lhr_sis
M
* kd_kls asl_sklh_sis
* kd_jrsn 1 thn_lls_sis
nli_ujn_nsnl_sisl
1
Kelas thn_msk_sis
Jurusan 1
* kd_kls
1 *kd_jrsn M * nis
* kd_jrsn * kd_jrsn
nm_kls M
Nm_jrsn
dy_tmpng
Nilai
1
Jam * kd_kls * nis
M * kd_mtpel
* kd_jm tgs
ktrngn 1 M Jadwal ulngn
mlai uts
slsai * kd_jm * kd_jdwl
uas
* kd_kls
hri M
* kd_jm * kd_matpel
Guru * kd_matpel
1 M
* nig M 1
* nig * kd_matpel
nm_gru * nig 1
almt_gru
tmp_lhr_gru Mata Pelajaran
tgl_lhr_gru Kelompok Mata Pelajaran
pass_gru 1 * kd_klmpk * kd_matpel
* kd_klmpk nm_matpel
Nm_klmpk_matpel M nli_kkm
* kd_klmpk

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 Ukuran Indeks
Field
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

uc Akses Aplikasi

Login

Staf
Guru
(from Use Case Model)
(from Use Case Model)
Logout

Gambar 3. 6 Paket use case diagram akses aplikasi

uc Master Data

Mengelola Jenis
Mengelola Jenis Pembayaran
Persyaratan

Mengelola Data
Staf Administrasi Mengelola Data
Sisw a

Mengelola Data
Guru

Mengelola Data Jam

Staf Mengelola Data

(from Use Case Model) Jurusan

Mengelola Data
Mengelola Data Kelas
Kelas Sisw a

Mengelola Data
Kelompok Mata
Pelaj aran Mengelola Data
Mata Pelaj aran

Gambar 3. 7 Paket use case diagram master data

 71

uc Transaksi

Mengelola Data
Pendaftaran

Memproses
Penerimaan Sisw a

Staf
(from Use Case Model)

Mengelola Data
Pembayaran
Mengelola Jadw al

Guru
(from Use Case Model)

Mengelola Data Nilai

Gambar 3. 8 Paket use case diagram transaksi

uc Laporan

Mencetak Laporan
Penerimaan Sisw a

Mencetak Laporan
Pembayaran

Staf

(from Use Case Model) Mencetak Nilai

Guru

Mencetak Jadw al (from Use Case Model)

Gambar 3. 9 Paket use case diagram laporan

 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
sd Interaction

Staf Guru FormLogin LoginController Staf Guru

inputUserId()

inputPassword()

klikLoginButton()

inputNig()

inputPassword()

klikLoginButton()

prosesLogin()

baca(userId, password) :boolean

baca(nig, password) :boolean

(from Use Case Model) (from Use Case Model)

Gambar 3. 10 Sequence diagram login

B. Sequence diagram logout

sd Interaction

Staf Guru FormUtama LogoutController

klikLogoutButton()

klikLogoutButton()

prosesLogout()

(from Use Case Model) (from Use Case Model)

Gambar 3. 11 Sequence diagram logout

 73

C. Sequence diagram mengelola jenis persyaratan

sd Interaction

Staf FormJenisPersyaratan FormDaftarJenisPersyaratan JenisPersyaratanController JenisPersyaratan

inputKodePersyaratan()

inputDataPersyaratan()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus()
hapus(kodeJenisPersyaratan)

klikDaftarButton()
tampilkanDaftar()
bacaData()

tampilkanData()

(from Use Case Model)

Gambar 3. 12 Sequence diagram mengelola jenis persyaratan

D. Sequence diagram mengelola jenis pembayaran

sd Interaction

Staf FormJenisPembayaran FormDaftarJenisPembayaran JenisPembayaranController JenisPembayaran

inputKodePembayaran()

inputDataPembayaran()

klikSimpanButton()

simpan()

simpan()

klikHapusButton()

hapus(kodeJenisPembayaran)
hapus(kodeJenisPembayaran)

klikDaftarButton()
tampilkanDaftar()
bacaData()

tampilkanData()

(from Use Case Model)

Gambar 3. 13 Sequence diagram mengelola jenis pembayaran

 74

E. Sequence diagram mengelola data staf administrasi

sd Interaction

Staf FormStafAdministrasi FormDaftarStafAdministrasi StafAdministrasiController StafAdministrasi

inputNoPegawai()

inputDataPegawai()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus(noPegawai)
hapus(noPegawai)

klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 14 Sequence diagram mengelola data staf administrasi

F. Sequence diagram mengelola data guru

sd Interaction

Staf Guru FormGuru FormDaftarGuru GuruController Guru

inputNig()

inputNig()

inpuDataGuru()

inputDataGuru()

klikSimpanButton()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()

klikHapusButton()
hapus(nig)
hapus(nig)

klikDaftarButton()

klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()

(from Use Case Model) (from Use Case Model)

Gambar 3. 15 Sequence diagram mengelola data guru

 75

G. Sequence diagram mengelola data siswa

sd Interaction

Staf FormSiswa FormDaftarSiswa SiswaController Siswa

inputNis()

inputDataSiswa()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
haspu(nis)
hapus(nis)

klikDaftarButton()

tampilkanDaftar()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 16 Sequence diagram mengelola data siswa

H. Sequence diagram mengelola kelompok mata pelajaran

sd Interaction

Staf FormKelompokMataKuliah FormDaftarKelompokMataKuliah KelompokMataKuliahController KelompokMataKuliah

inputKodeKelompokMataKuliah()

inputDataKelompokMataKuliah()

klikSimpanButton()

simpan()
simpan()

klikHapusButton()
hapus(kodeKelompokMataKuliah)

hapus(kodeKelompokMataKuliah)

klikDaftarButton()
tampilkanDaftar()
bacaData()

tampilkanData()

(from Use Case Model)

Gambar 3. 17 Sequence diagram mengelola kelompok mata pelajaran

 76

I. Sequence diagram mengelola mata pelajaran

sd Interaction

Staf FormMataPelajaran FormDaftarMataPelajaran MataPelajaranController MataPelajaran

inputKodeMataPelajaran()

inputDataMataPelajaran()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus(kodeMataPelajaran)
hapus(kodeMataPelejaran)

klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 18 Sequence diagram mengelola mata pelajaran

J. Sequence diagram mengelola data jam

sd Interaction

Staf FormJam FormDaftarJam JamController Jam

inputKodeJam()

inputDataJam()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus(kodeJam)
hapus(kodeJam)

klikDaftarButton()

tampilkanDaftarJam()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 19 Sequence diagram mengelola data jam

 77

K. Sequence diagram mengelola data jurusan

sd Interaction

Staf FormJurusan FormDaftarJurusan JurusanController Jurusan

inputKodeJurusan()

inputDataJurusan()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus(kodeJurusan)
hapus(kodeJurusan)

klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 20 Sequence diagram mengelola data jurusan

L. Sequence diagram mengelola data kelas

sd Interaction

Staf FormKelas FormDaftarKelas KelasController Kelas

inputDataKelas()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus()
hapus()

klikDaftarButton()
tampilkanDaftar()
bacaData()

tampilkanData()

(from Use Case Model)

Gambar 3. 21 Sequence diagram mengelola data kelas

 78

M. Sequence diagram mengelola data kelas siswa

sd Interaction

Staf FormKelasSiswa FormDaftarKelasSiswa KelasSiswaController KelasSiswa

inputDataKelasSiswa()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus()
hapus()

klikDaftarButton()
tampilkanDaftar()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 22 Sequence diagram mengelola data kelas siswa

N. Sequence diagram mengelola data pendaftaran

sd Interaction

Staf FormPendaftaran PendaftaranController CalonSiswa

inputNoPendaftaran()

inputDataCalonSiswa()

inputKelengkapanPersyaratan()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus()
hapus()

klikDaftarButton()
tampilkanDaftarCalonSiswa()
bacaData()
tampilkanData()

(from Use Case Model)

Gambar 3. 23 Sequence diagram mengelola data pendaftaran

 79

O. Sequence diagram diagram proses penerimaan siswa

sd Interaction

Staf FormPenerimaanSiswa PenerimaanSiswaController CalonSiswa Siswa KelasSiswa

inputTahunAjaran()
hitungJumlahCalonSiswa()
bacaData()
setJumlahCalonSiswa()

klikProsesPenerimaanSiswaButton()
prosesPenerimaanSiswa()
bacaData()
setJumlahDiterima()

klikSimpanButton()
simpan()
bacaData()

simpan()

simpan()

(from Use Case Model)

Gambar 3. 24 Sequence diagram diagram proses penerimaan siswa

P. Sequence diagram mengelola data pembayaran

sd Interaction

Staf 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()

(from Use Case Model)

Gambar 3. 25 Sequence diagram mengelola data pembayaran

 80

Q. Sequence diagram mengelola jadwal

sd Interaction

Staf FormJadwal FormDaftarJadwal JadwalController Jadwal Kelas MataPelajaran Guru Jam

bukaForm()
aturTampilanAwal()
bacaData()
setItemKelasComboBox()
bacaData()
setItemMataPelajaranComboBox()
bacaData()
setItemGuruComboBox()
bacaData()
setItemJamComboBox()

inputKodeJadwal()
cari(kodeJadwal)
baca(kodeJadwal)
tampilkanDataJadwal()

klikDaftarButton()
tampilkanDaftarJadwal()
bacaData()
tampilkanData()

klikPilihButton()
tampilkanDataJadwal()
baca(kodeDipilih)
tampilkanDataJadwal()

klikSimpanButton()
simpan()
simpan()

klikHapusButton()
hapus(kodeJadwal)
hapus(kodeJadwal)

(from Use Case Model)

Gambar 3. 26 Sequence diagram mengelola jadwal

 81

R. Sequence diagram mengelola data nilai

sd Interaction

Guru FormNilai FormDaftarJadwal NilaiController Nilai Jadwal KelasSiswa MataPelajaran Siswa

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()

(from Use Case Model)

Gambar 3. 27 Sequence diagram mengelola data nilai

 82

S. Sequence diagram mencetak laporan penerimaan siswa

sd Interaction

Staf FormLaporanPenerimaanSiswa PenerimaanSiswaController Siswa

inputTahunAjaran()

klikCetakButton()

cetakPenerimaanSiswa(tahunAjaran)

cetakSiswaBaru(tahunAjaran)

(from Use Case Model)

Gambar 3. 28 Sequence diagram mencetak laporan penerimaan siswa

T. Sequence diagram mencetak laporan pembayaran

sd Interaction

Staf FormLaporanPembayaran Pembayaran Siswa

klikCetakButton()

cetakPembayaran()

cetak()

(from Use Case Model)

Gambar 3. 29 Sequence diagram mencetak laporan pembayaran

 83

U. Sequence diagram mencetak laporan nilai

sd Interaction

Staf Guru FormLaporanNilai NilaiController Nilai

klikCetakButton()
cetakNilai()
cetak()

klikCetakButton()
cetakNilai()
cetak()

(from Use Case Model) (from Use Case Model)

Gambar 3. 30 Sequence diagram mencetak laporan nilai

V. Sequence diagram mencetak laporan jadwal

sd Interaction

Staf Guru FormLaporanJadwal JadwalController Jadwal

klikCetakButton()
cetakJadwal()
cetak()

klikCetakButton()
cetakJadwal()
cetak()

(from Use Case Model)(from Use Case Model)

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

A. Activity diagram login

act Activ ity

Mulai

Input User ID (atau NIG)

dan passw ord

valid?
[Ya]

Masuk ke dalam
[Tidak] sistem/aplikasi dan aktifkan
menu sesuai hak aksesnya

Selesai

Gambar 3. 32 Activity diagram login

B. Activity diagram logout

act Activ ity

Mulai

Klik tombol Logout

Disable semua menu

Selesai

Gambar 3. 33 Activity diagram logout

 85

C. Activity diagram mengelola jenis persyaratan

act Activ ity

Mulai

Input kode j enis persyaratan, nama

persyaratan, j umlah, dan satuan Klik tombol daftar

Tampilkan daftar j enis

persyaratan

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak]

Simpan data (update/insert) Hapus data j enis

j enis persyaratan persyaratan [Ya]

Tampilkan data j enis

persyaratan yang dipilih

Selesai

Gambar 3. 34 Activity diagram mengelola jenis persyaratan

 86

D. Activity diagram mengelola jenis pembayaran

act Activ ity

Mulai

Input kode j enis pembayaran, nama

pembayaran, j angka, dan satuan Klik tombol daftar

Tampilkan daftar j enis

pembayaran

Klik tombol simpan Klik tombol hapus

Ada yang dipilih?

[Tidak]
Simpan data (update/insert) Hapus data j enis
j enis pembayaran pembayaran
[Ya]

Tampilkan data j enis

pembayaran yang dipilih

Selesai

Gambar 3. 35 Activity diagram mengelola jenis pembayaran

 87

E. Activity diagram mengelola data staf administrasi

act Activ ity

Mulai

Input no. pegaw ai, nama, alamat,

tempat lahir, tanggal lahir, dan Klik tombol daftar
passw ord

Tampilkan daftar staf

administrasi

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak]
Simpan data (update/insert) Hapus data staf
staf administrasi administrasi [Ya]

Tampilkan data staf

administrasi yang dipilih

Selesai

Gambar 3. 36 Activity diagram mengelola data staf administrasi

 88

F. Activity diagram mengelola data guru

act Activ ity

Mulai

Input NIG, nama, alamat, tempat

lahir, tanggal lahir, dan passw ord Klik tombol daftar

Tampilkan daftar guru

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak]
Simpan data (update/insert) Hapus data guru
guru [Ya]

Tampilkan data guru yang

dipilih

Selesai

Gambar 3. 37 Activity diagram mengelola data guru

 89

G. Activity diagram mengelola data siswa

act Activ ity

Mulai

Input no. pegaw ai, nama, alamat, tempat Klik tombol daftar
lahir, tanggal lahir, asal sekolah, tahun
lulus, dan nilai uj ian nasional

Tampilkan daftar sisw a

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak]
Simpan data (update/insert) Hapus data sisw a
sisw a [Ya]

Tampilkan data sisw a

yang dipilih

Selesai

Gambar 3. 38 Activity diagram mengelola data siswa

 90

H. Activity diagram mengelola kelompok mata pelajaran

act Activ ity

Mulai

Input kode kelompok, dan nama

kelompok Klik tombol daftar

Tampilkan daftar
kelompok mata pelaj aran

Klik tombol simpan Klik tombol hapus

Ada yang dipilih?

[Tidak]

Simpan (update/insert) data Hapus data kelompok

kelompok mata pelaj aran mata pelaj aran [Ya]

Tampilkan data kelompok

mata pelaj aran yang dipilih

Selesai

Gambar 3. 39 Activity diagram mengelola kelompok mata pelajaran

 91

I. Activity diagram mengelola mata pelajaran

act Activ ity

Mulai

Input kode mata pelaj aran, dan nama Klik tombol daftar
mata pelaj aran

Tampilkan daftar mata

pelaj aran

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak]

Simpan data (update/insert) Hapus data mata

mata pelaj aran pelaj aran [Ya]

Tampilkan data mata

pelaj aran yang dipilih

Selesai

Gambar 3. 40 Activity diagram mengelola mata pelajaran

 92

J. Activity diagram mengelola data jam

act Activ ity

Mulai

Input kode j am, keterangan, mulai,

dan selesai Klik tombol daftar

Tampilkan daftar j am

Klik tombol simpan Klik tombol hapus

Ada yang dipilih?

[Tidak]
Simpan (update/insert) data Hapus data j am
j am [Ya]

Tampilkan data j am yang

dipilih

Selesai

Gambar 3. 41 Activity diagram mengelola data jam

 93

K. Activity diagram mengelola data jurusan

act Activ ity

Mulai

Input kode j urusan, dan nama

j urusan Klik tombol daftar

Tampilkan daftar j urusan

Klik tombol simpan Klik tombol hapus

Ada yang dipilih?

[Tidak]
Simpan (update/insert) data Hapus data j urusan
j urusan [Ya]

Tampilkan data j urusan

yang dipilih

Selesai

Gambar 3. 42 Activity diagram mengelola data jurusan

 94

L. Activity diagram mengelola data kelas

act Activ ity

Mulai

Input tahun aj aran, semester, tingkat, Klik tombol daftar

kode j urusan, urutan kelas, dan daya
tampung

Tampilkan daftar kelas

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak]

Simpan (update/insert) data Hapus data kelas

kelas [Ya]

Tampilkan data kelas yang

dipilih

Selesai

Gambar 3. 43 Activity diagram mengelola data kelas

 95

M. Activity diagram mengelola data kelas siswa

act Activ ity

Mulai

Input tahun aj aran, semester, tingkat, Klik tombol daftar

kode j urusan, urutan kelas, dan nis

Tampilkan daftar kelas

sisw a

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?

Simpan (update/insert) data Hapus data kelas sisw a

kelas sisw a
[Ya]

[Tidak] Tampilkan data kelas sisw a

yang dipilih

Selesai

Gambar 3. 44 Activity diagram mengelola data kelas siswa

 96

N. Activity diagram mengelola data pendaftaran

act Activ ity

Mulai

Input tahun aj aran, no. pendaftaran,

data sisw a, dan data kelengkapan Klik tombol daftar
persyaratan

klik tombol no.

pendaftaran baru

Tampilkan daftar calon

sisw a

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak] tampilkan no. pendaftaran
baru
Simpan (update/insert) data Hapus data calon sisw a
calon sisw a [Ya]

Tampilkan data calon

sisw a yang dipilih

Selesai

Gambar 3. 45 Activity diagram mengelola data pendaftaran

 97

O. Activity diagram proses penerimaan siswa

act Activ ity

Mulai

Tampilkan j umlah calon sisw a,

dan daya tampung

Klik tombol proses

penerimaan
Klik tombol simpan

Urutkan calon sisw a berdasarkan

j urusan yang dipilih, nilai uj ian
nasional (desc), tahun lulus (desc),
dan no pendaftaran. Simpan semua data calon
sisw a yang telah
dialokasikan ke dalam
tabel sisw a

Alokasikan calon sisw a dalam

kelas sesuai daya tampung

Selesai

Gambar 3. 46 Activity diagram proses penerimaan siswa

 98

P. Activity diagram mengelola data pembayaran

act Activ ity

Mulai

Input no. pembayaran, data sisw a,

dan data pembayaran Klik tombol daftar

klik tombol no.

pembayaran baru

Tampilkan daftar
pembayaran

Klik tombol simpan Klik tombol hapus

Ada yang
dipilih?
[Tidak] tampilkan no. pembayaran
baru
Simpan (update/insert) data Hapus data pembayaran
pembayaran [Ya]

Tampilkan data
pembayaran yang dipilih

Selesai

Gambar 3. 47 Activity diagram mengelola data pembayaran

 99

Q. Activity diagram mengelola jadwal

act Activ ity

Mulai

Input data nilai Klik tombol daftar

Input kode Jadw al

Tampilkan daftar j adw al

Klik tombol simpan

Ada yang Tampilkan data j adw al

dipilih? yang dipilih
Simpan data nilai [Ya]

[Tidak] Tampilkan data sisw a

dan nilainya

Selesai

Gambar 3. 48 Activity diagram mengelola jadwal

 100

R. Activity diagram mengelola data nilai

act Activ ity

Mulai

Klik tombol daftar

Input nilai sisw a

Tampilkan daftar j adw al

Klik tombol simpan

Ada yang
dipilih?
[Tidak]

Simpan data nilai sisw a

[Ya]

Tampilkan data sisw a

sesuai j adw al yang dipilih

Selesai

Gambar 3. 49 Activity diagram mengelola data nilai

 101

S. Activity diagram mencetak laporan penerimaan siswa

act Activ ity

Mulai

Input tahun aj aran

Tombol cetak diklik Tombol tutup diklik

Cetak data penerimaan sisw a Tutup form

sesuai tahun aj aran yang diinput

Selesai

Gambar 3. 50 Activity diagram mencetak laporan penerimaan siswa

 102

T. 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 Tutup form

Selesai

Gambar 3. 51 Activity diagram mencetak laporan pembayaran

 103

U. Activity diagram mencetak laporan nilai

act Activ ity

Mulai

Tampilkan pilihan Nilai

yang akan dicetak

Tombol cetak diklik Tombol tutup diklik

Cetak nilai Tutup form

Selesai

Gambar 3. 52 Activity diagram mencetak laporan nilai

 104

V. Activity diagram mencetak laporan jadwal

act Activ ity

Mulai

Tampilkan pilihan j adw al

yang akan dicetak

Tombol cetak diklik Tombol tutup diklik

Cetak data j adw al Tutup form

Selesai

Gambar 3. 53 Activity diagram mencetak laporan jadwal

 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

custom Aplikasi

Form Login

User ID

Password

Status Staf Administrasi

Login Batal

Gambar 3. 56 Desain antarmuka form login

 107

C. Desain antarmuka informasi aplikasi

custom Aplikasi

Informasi Aplikasi

Aplikasi Administrasi Sekolah

SMK AVERUS JAKARTA

Oleh: Yulianti
NIM: 2009140661
Universitas Pamulang 2013

Gambar 3. 57 Desain antarmuka informasi aplikasi

D. Desain antarmuka master data jenis persyaratan

custom Master Data

Master Data Jenis Persyaratan

Kode Persyaratan Daftar

Nama Persyaratan

Satuan

Jumlah

Simpan Hapus Tutup

Gambar 3. 58 Desain antarmuka master data jenis persyaratan

 108

E. Desain antarmuka master data jenis pembayaran

custom Master Data

Master Data Jenis Pembayaran

Kode Jenis Pembayaran Daftar

Nama Jenis Pembayaran

Jumlah Pembayaran

Jangka Waktu

Satuan

Simpan Hapus Tutup

Gambar 3. 59 Desain antarmuka master data jenis pembayaran

 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:

109
 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 Hasil Kesimpulan
. diharapkan pengujian
1 Memilih (mengklik) Klik menu item Menampilkan Sesuai valid
menu login login form login harapan
2 Mengosongkan form Jabatan dipilih Menampilkan Sesuai valid
login, kemudian staf keterangan harapan
mengklik button administrasi, no. no. pegawai
login pegawai kosong, harus diisi
password
kosong
3 Melakukan login Jabatan dipilih Berhasil login Sesuai valid
dengan memilih staf dan menu harapan
jabatan staf dengan administrasi, no. untuk staf
data yang benar pegawai diisi administrasi
ADMIN, dan diaktifkan
password diisi
ADMIN
4 Mengosongkan kode Kode Aplikasi Sesuai Valid
persyaratan pada persyaratan = ”” menampilkan harapan
form master data pesan “Kode
jenis persyaratan, persyaratan
kemudian mengklik tidak boleh
tombol simpan kosong”
5 Mengosongkan kode Kode Aplikasi Sesuai Valid
persyaratan pada persyaratan = ”” menampilkan harapan
form master data pesan “Kode
jenis persyaratan, persyaratan
kemudian mengklik tidak boleh
tombol hapus kosong”
 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.
 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.

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

126
 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