BAB 2 LANDASAN TEORI

BAB 2
LANDASAN TEORI
2.1 Teori-Teori Umum
Pada teori umum disajikan teori yang relevan, lengkap, dan urut sejalan
dengan permasalahan. Teori yang dikemukakan berasal dari sumber teori dan dari
hasil penelitian. Teori-teori yang akan dibahas antara lain :
2.1.1
Teori-Teori Dasar Sistem Basis Data
Pembahasan teori yang akan dibahas pada subbab berikut ini adalah
pembahasan teori dasar yang berhubungan dengan sistem basis data.
2.1.1.1
Pengertian Sistem
Menurut Hall (2011, p5), sistem adalah sekelompok dua atau lebih
komponen yang saling berkaitan atau subsistem yang bersatu untuk mencapai
tujuan yang sama.
2.1.1.2
Pengertian Data
Menurut Connolly dan Begg (2010, p19), data adalah komponen yang
paling penting dalam DBMS, berasal dari sudut pandang pengguna terakhir. Data
bertindak sebagai jembatan antara mesin dan pengguna.
8
9
2.1.1.3
Pengertian Basis Data
Menurut Connolly dan Begg (2010, p65), basis data adalah sekumpulan data
yang terhubung satu sama lain secara logika dan deskripsi data yang dirancang
untuk memenuhi kebutuhan informasi suatu organisasi.
2.1.1.4
Pengertian Sistem Basis Data
Menurut Connolly dan Begg (2010, p87), sistem basis data adalah kumpulan
dari program aplikasi yang berinteraksi dengan basis data.
2.1.2
Pengertian Analisis dan Perancangan
Pada bagian subbab berikut ini hanya akan membahas pengertian analisis
dan perancangan.
2.1.2.1
Pengertian Analisis
Menurut Bentley dan Whitten (2007, p160), analisis adalah teknik untuk
menyelesaikan masalah pada suatu sistem dengan cara membagi masalah tersebut
kebeberapa bagian dengan maksud agar mudah dicari penyelesaiannya.
2.1.2.2
Pengertian Perancangan
Menurut Bentley dan Whitten (2007, p160), perancangan adalah teknik
menggabungkan bagian informasi yang telah dipisahkan oleh analisis sistem.
10
2.1.3
Database Management System (selanjutnya disingkat DBMS)
Teori yang akan dibahas pada pembahasan DBMS adalah pengertian,
fungsi, komponen, keuntungan, dan kerugian dari DBMS.
2.1.3.1
Pengertian DBMS
Menurut Hoffer et. al. (2009, p49), DBMS adalah sebuah sistem perangkat
lunak yang menyediakan metode sistematis untuk menciptakan, memperbaharui,
menyimpan, dan mengambil data dalam basis data.
2.1.3.2
Fungsi DBMS
Menurut Connolly dan Begg (2010, p99), fungsi DBMS adalah :
a.
Data storage, retrieval, dan update
DBMS harus melengkapi pengguna dengan kemampuan untuk menyimpan,
mengambil, dan mengubah data di dalam basis data.
b.
A user-accessible catalog
DBMS harus menyediakan katalog yang menggambarkan data yang
disimpan dan yang dapat diakses oleh pengguna.
c.
Transaction support
DBMS harus menyediakan mekanisme yang akan memastikan apakah
semua perubahan cocok dengan transaksi yang dilakukan atau tidak.
11
d.
Concurrency control services
DBMS harus menyediakan mekanisme yang memastikan basis data diubah
dengan benar ketika pengguna mengubah basis data secara bersamaan.
e.
Recovery services
DBMS harus menyediakan mekanisme untuk memperbaiki basis data pada
saat basis data rusak.
f.
Authorization services
DBMS harus menyediakan mekanisme yang akan memastikan bahwa hanya
pengguna yang memiliki hak yang dapat mengakses basis data.
g.
Support for data communication
DBMS harus dapat berintegrasi dengan perangkat lunak komunikasi.
h.
Integrity service
DBMS harus memberikan cara untuk memastikan data di dalam basis data
dan perubahan-perubahan mengikuti aturan-aturan tertentu.
i.
Services to promote data independence
DBMS harus mencakup fasilitas untuk mendukung program yang tidak
bergantung dari struktur basis data yang sebenarnya.
j.
Utility service
DBMS harus menyediakan kumpulan keperluan layanan.
12
2.1.3.3
Komponen dalam Lingkungan DBMS
Menurut Connolly dan Begg (2010, p68), ada lima komponen utama
DBMS, seperti terlihat pada Gambar 2.1. Lima komponen tersebut adalah :
a.
Perangkat Keras
Perangkat keras digunakan oleh DBMS untuk beroperasi serta untuk
menjalankan DBMS dan aplikasi. Perangkat keras dapat mencakup single
personal computer, single mainframe hingga jaringan komputer.
b.
Perangkat Lunak
Komponen perangkat lunak dalam DBMS terdiri dari perangkat lunak
DBMS dan program aplikasi, bersama sistem operasi, termasuk perangkat
lunak jaringan jika DBMS digunakan dalam sebuah jaringan.
c.
Data
Data merupakan komponen perangkat lunak yang paling penting di dalam
lingkungan DBMS menurut sudut pandang pengguna akhir. Data berperan
sebagai penghubung antara komponen mesin dan manusia.
d.
Prosedur
Prosedur mencakup instruksi dan aturan yang menentukan rancangan dan
kegunaan basis data. Pengguna sistem dan pegawai yang mengatur basis
data membutuhkan dokumentasi prosedur bagaimana menjalankan sistem.
e.
Manusia
Manusia yang terlibat adalah Database Adminisator (selanjutnya disingkat
DBA), perancangan basis data, pengembang aplikasi, dan pengguna akhir.
13
Gambar 2.1 Komponen Utama DBMS
Menurut Connolly dan Begg (2010, p69), ada empat tipe yang terlibat dalam
lingkungan DBMS yaitu :
1)
Data Administrator dan Database Administrator
Data Administrator (selanjutnya disingkat DA) bertanggung jawab untuk
mengatur sumber data meliputi perencanaan basis data, standar pengaturan
dan pengembangan, kebijakan dan prosedur, dan rancangan konseptual dan
logikal basis data dan Database Adminisator (DBA) bertanggung jawab
dalam realisasi fisik basis data, meliputi rancangan fisikal basis data dan
implementasi, keamanan dan pengaturan integritas, menjaga sistem
operasional, dan memastikan kinerja aplikasi untuk kepuasan pengguna.
2)
Database Designers
Perancang basis data logikal berhubungan dengan identifikasi data termasuk
entitas dan atribut, relasi antara data, dan batasan pada data untuk disimpan
di basis data. Perancang basis data fisikal memutuskan bagaimana
rancangan basis data logikal dapat direalisasikan.
14
3)
Application developers
Application developers bertanggung jawab untuk mengimplementasikan
program aplikasi yang menyediakan syarat-syarat fungsionalitas untuk
pengguna terakhir.
4)
End Users
End users adalah relasi basis data yang dirancang, diimplementasikan dan
dijaga untuk menyediakan kebutuhan informasi mereka.
2.1.3.4
Keuntungan dan Kerugian DBMS
Menurut Connolly dan Begg (2010, p77), pengguna DBMS mempunyai
keuntungan-keuntungan sebagai berikut yaitu mengontrol redundansi data,
konsistensi data, banyaknya informasi diperoleh dari sumber, mampu membagi
data, meningkatkan integritas data, meningkatkan keamanan, meningkatkan
standar, dan meningkatkan backup dan pemulihan.
Menurut Connolly dan Begg (2010, p77), pengguna DBMS mempunyai
kerugian-kerugian sebagai berikut yaitu kompleks, memerlukan ukuran perangkat
lunak yang sangat besar, biaya untuk menghasilkan DBMS yang baik sangat
mahal, pengeluaran untuk perangkat keras tambahan, biaya untuk konversi sistem
dari sistem yang lama ke sistem baru, dan membawa pengaruh yang besar kepada
perusahaan apabila terjadi kegagalan.
15
2.1.4
Siklus Hidup Aplikasi Basis Data
Menurut Connolly dan Begg (2010, p314), siklus hidup aplikasi basis data
adalah bagian penting bagi sistem informasi perusahaan, dengan demikian daur
pembuatan dalam aplikasi basis data sering dihubungkan dengan daur pembuatan
dalam sistem informasi. Skema siklus hidup aplikasi basis data dapat dilihat pada
Gambar 2.2.
Gambar 2.2 Siklus Hidup Aplikasi Basis Data
16
2.1.4.1
Perencanaan Basis Data
Menurut Mackin dan Hotek (2010, p15), perencanaan basis data adalah
keadaan pada saat penulis belum menampilkan database server, penulis harus
mengumpulkan sebanyak mungkin informasi tentang lingkungan database server.
Yang harus dilakukan adalah merancang kebutuhan kapasitas, spesifikasikan
versi konfigurasi perangkat lunak dan keras, dan merancang penyimpanan fisikal.
Sedangkan menurut Taylor (2011, p193), perencanaan basis data adalah
suatu perencanaan sebelum penulis mulai mengkonstruksikan basis data, penulis
harus mempunyai ide yang jelas atau sistem konseptual yang telah dimodelkan.
2.1.4.2
Definisi Sistem
Menurut Connolly dan Begg (2010, p316), definisi sistem adalah
penggambaran lingkup dan batasan-batasan dari aplikasi basis data dan tampilan
pengguna yang utama. Hal ini sangat penting dilakukan dalam proses
perancangan basis data agar lebih terfokus pada proyek basis data yang dibuat.
2.1.4.3
Analisis dan Pengumpulan Kebutuhan
Menurut Connolly dan Begg (2010, p316), analisis dan pengumpulan
dilakukan proses pengumpulan dan analisis informasi tentang bagian organisasi
yang akan didukung oleh aplikasi basis data dan menggunakan informasi ini
untuk mengidentifikasikan kebutuhan pengguna terhadap sistem yang baru.
17
Sedangkan menurut Alapati (2009, p23), analisis dan pengumpulan
kebutuhan adalah langkah pertama dalam mendesain basis data baru. Yang perlu
dicari adalah proses iteratif dan pengumpulan basis data organisasi.
2.1.4.4
Desain Basis Data
Menurut Chapple (2008, p64), desain basis data adalah proses setelah
penulis menormalisasi desain dan memerlukan entity relationship diagram ke
dalam SQL server untuk merancang basis data. Tugas yang paling utama adalah
menunjukkan pemilihan tipe data pada tiap atribut di basis data.
2.1.4.5
Seleksi DBMS
Menurut Ponniah (2010, p120), seleksi DBMS adalah proses saat tahap
definisi kebutuhan, penulis mewawancara pengguna, dan melakukan pertemuan
formal dengan pewawancara, tetapi tidak keseluruhan membicarakan tipe DBMS
yang akan dipilih secara lugas.
Sedangkan menurut Pratt dan Adamski (2008, p11), seleksi DBMS adalah
suatu proses penting, pada saat angka sesuai dengan sistem yang tersedia dari
pilihan yang ada. Sayangnya, menyeleksi DBMS yang benar bukan tugas yang
mudah. Untuk mempersiapkan sumber daya manusia yang baik dan bekerja
dengan efektif di sebuah area, dibutuhkan proses seleksi yang komprehensif yang
mana dibantu dengan asisten yang baik maka terjadilah sebuah proses seleksi.
18
2.1.4.6
Desain Aplikasi
Menurut Olson (2009, p65), desain aplikasi adalah keadaan pada saat
penulis telah mengumpulkan data tentang aplikasi dan yang dibutuhkan
selanjutnya adalah mendesain data serta kebijakan yang akan dipakai selanjutnya.
Sedangkan menurut Oppel (2010, p82), desain aplikasi adalah bagian
sempurna dan konstruksi dari permulaan suatu aplikasi yang dapat menemukan
kegunaan untuk mengartikan suatu kerangka disetiap proyek yang diminta.
2.1.4.7
Prototipe
Menurut Ritchie (2008, p5), prototipe adalah proses yang mendasar dari
mengembangkan sistem secara penuh pada langkah investigasi, merancang
implementasi dan tiap perancangan menyajikan implementasi parsial yang mana
mencoba menunjukkan rancangan, dan mendemonstrasikan sistem ke pengguna.
2.1.4.8
Implementasi
Menurut Agarwal dan Huddleston (2008, p28), implementasi adalah proses
dari tahapan yang dapat dibagi menjadi tahap-tahap kecil, hanya setelah
menyelesaikan setiap tahap dan dapat meneruskan tahap selanjutnya.
19
2.1.4.9
Konversi Data dan Pemuatan
Menurut Giachetti (2010, p411), konversi data dan pemuatan adalah skema
perbedaan antara sistem yang baru dan yang lama, serta memiliki pengaruh pada
konversi yang dianalisis dan disetujui pada konversi data yang telah dibuat.
2.1.4.10 Pengujian
Menurut Carpenter (2010, p52), pengujian adalah tahap mudah, basis data
diuji kegunaannya, performanya, keamanannya, dan peningkatannya.
2.1.4.11 Pemeliharaan Operasional
Menurut Shelly dan Rosenblatt (2011, p574), pemeliharaan operasional
adalah beban selama masa manfaat sistem. Biaya operasional meliputi
persediaan, sewa peralatan, dan sewa perangkat lunak. Biaya perawatan
bervariasi secara signifikan selama sistem berjalan, operasional, dan termasuk
pengeluaran untuk mendukung kegiatan pemeliharaan.
2.1.5
Normalisasi
Teori yang akan dibahas pada bagian normalisasi berikut ini adalah
mengenai pengertian normalisasi, tujuan normalisasi, dan tahapan normalisasi.
20
2.1.5.1
Pengertian Normalisasi
Menurut Connolly dan Begg (2010, p416), normalisasi adalah sebuah teknik
untuk menghasilkan sejumlah relasi dengan sifat-sifat yang diinginkan sehingga
dapat memenuhi kebutuhan data pada perusahaan.
2.1.5.2
Tujuan Normalisasi
Menurut Stephens (2009, p61), tujuan normalisasi adalah mengatur kembali
basis data untuk dimasukkan ke dalam form standar untuk mencegah anomali.
2.1.5.3
Tahap-Tahap Normalisasi
Menurut Connolly dan Begg (2010, p430), bentuk proses normalisasi dapat
dijelaskan sebagai berikut :
a.
Unnormalized Form (selanjutnya disingkat UNF)
UNF adalah tabel yang berisi atau lebih repeating group. Dari bentuk inilah
dilakukan proses normalisasi.
b.
First Normal Form (selanjutnya disingkat 1NF)
1NF merupakan sebuah relasi pada saat setiap irisan dari masing-masing
baris dan kolom berisi satu dan hanya satu nilai.
21
c.
Second Normal Form (selanjutnya disingkat 2NF)
Pada tahap ini perancang harus menghilangkan partial dependencies pada
primary key. 2NF didasarkan pada konsep full functional dependency, yaitu jika
A dan B merupakan atribut, B dikatakan full functional dependency terhadap A,
tetapi tidak ada proper subset dari A. 2NF sendiri memiliki pengertian sebuah
relasi dalam 1NF dan setiap atribut non primary key bersifat full functional
dependent terhadap primary key.
d.
Third Normal Form (selanjutnya disingkat 3NF)
Pada tahap ini perancang harus menghilangkan transitive dependencies pada
primary key. Berdasarkan pada konsep transitive dependency, yaitu suatu kondisi
di mana A, B, dan C merupakan atribut dari sebuah relasi, maka jika A→B dan
B→C, maka C transitively dependent pada A melalui B. Ini terjadi jika A tidak
functionally dependent pada B atau C. 3NF sendiri memiliki pengertian sebuah
relasi dalam 1NF dan 2NF, dan di mana tidak ada atribut non primary key yang
bersifat transitively dependent terhadap primary key.
2.1.6
Entity Relationship Modeling
Menurut Connolly dan Begg (2010, p371), entity relationship modeling
adalah pendekatan perancangan basis data top down yang dimulai dengan
mengidentifikasikan data yang penting yang disebut dengan entitas dan hubungan
diantara data yang harus dipresentasikan dalam model.
22
2.1.6.1
Tipe Entitas
Menurut Connolly dan Begg (2010, p372), tipe entitas adalah kumpulan dari
objek dengan sifat yang sama, yang diidentifikasi oleh perusahaan yang
mempunyai eksistensi yang independen, seperti yang terlihat pada Gambar 2.3.
Gambar 2.3 Contoh Tipe Entitas
Menurut Connolly dan Begg (2010, p383), tipe entitas kuat adalah entitas
yang keberadaannya tidak bergantung pada beberapa entitas lain. Karakter entitas
ini adalah bahwa setiap kejadian entitas teridentifikasi secara unik menggunakan
atribut primary key. Tipe entitas kuat biasa disebut parent atau owner dominant.
Sedangkan tipe entitas lemah adalah entitas yang keberadaannya tergantung
pada beberapa entitas yang lain. Karakter dari entitas ini adalah bahwa setiap
kejadian entitas tidak dapat teridentifikasi secara unik hanya dengan
menggunakan atribut yang berhubungan dengan entitas tersebut. Tipe entitas
lemah biasa disebut dengan child, dependent, dan subordinate.
23
2.1.6.2
Tipe Relasi
Menurut Connolly dan Begg (2010, p374), tipe relasi adalah sekumpulan
hubungan antara satu atau lebih tipe entitas yang berpartisipasi. Setiap tipe relasi
diberikan nama yang mendeskripsikan fungsinya.
2.1.6.3
Atribut
Menurut Connolly dan Begg (2010, p379), atribut adalah sifat-sifat dari
sebuah entitas atau tipe relasi. Setiap atribut diperbolehkan untuk memiliki nilai
yang disebut dengan domain. Atribut domain adalah kumpulan dari nilai yang
diperbolehkan untuk satu atau lebih atribut.
2.1.6.4
Keys
Menurut Connolly dan Begg (2010, p381), candidate key didefinisikan
sebagai sejumlah atribut yang secara unik dapat mengidentifikasi suatu entitas.
Primary key didefinisikan sebagai candidate key yang dipilih secara unik
mengidentifikasikan setiap peristiwa dari sebuah tipe entitas. Composite key
didefinisikan sebagai candidate key yang terdiri atas dua atau lebih atribut.
Foreign key adalah sembarang atribut pada primary key pada tabel berikutnya
yang berfungsi menghubungkan antar tabel apabila sebuah primary key terhubung
dengan tabel berikutnya.
24
2.1.6.5
Batasan Struktural
Menurut Connolly dan Begg (2010, p385), multiplicity adalah jumlah
kejadian yang mungkin terjadi pada sebuah tipe entitas yang berhubungan ke
sebuah occurrrence dari tipe entitas lain pada suatu relasi.
Menurut Connolly dan Begg (2010, p385), tiga macam hubungan binary
secara umum, seperti terlihat pada Gambar 2.4 sampai Gambar 2.6.
a.
Derajat hubungan one-to-one (1:1)
Derajat hubungan (1:1) terjadi apabila tiap anggota suatu entitas hanya
boleh berpasangan dengan satu anggota dari entitas yang lain. Begitu juga
sebaliknya, anggota dari entitas yang lain hanya boleh mempunyai satu
anggota dari entitas tersebut.
Gambar 2.4 Multiplicity dengan Tipe Relasi (1:1)
25
b.
Derajat hubungan one-to-many (1:*)
Derajat hubungan (1:*) terjadi apabila tiap anggota suatu entitas memiliki
lebih dari satu anggota dari entitas yang lain. Begitu juga sebaliknya,
anggota dari entitas yang lain hanya boleh berpasangan dengan satu anggota
dari entitas tersebut.
Gambar 2.5 Multiplicity dengan Tipe Relasi (1:*)
c.
Derajat hubungan many-to-many (*:*)
Derajat hubungan (*:*) terjadi apabila tiap anggota suatu entitas memiliki
lebih dari satu anggota dari entitas yang lain dan juga entitas yang lain
memiliki lebih dari satu anggota dari entitas tersebut.
Gambar 2.6 Multiplicity dengan Tipe Relasi (*:*)
26
2.1.7
Perancangan Basis Data
Menurut Connolly dan Begg (2010, p320), perancangan basis data adalah
proses pembuatan sebuah rancangan untuk sebuah basis data yang mendukung
operasi tujuan dari perusahaan.
2.1.7.1
Perancangan Basis Data Konseptual
Menurut Nyerges dan Jankowski (2010, p103), perancangan basis data
konseptual adalah umumnya terdiri dari satu set simbol sederhana yang dapat
digunakan untuk menyusun diagram.
Menurut Connolly dan Begg (2010, p322), langkah dalam perancangan
basis data konseptual yaitu :
Langkah pertama adalah membangun model data konseptual lokal untuk
setiap tampilan. Langkah ini memiliki langkah selanjutnya yaitu :
a.
mengidentifikasi tipe entitas,
b.
mengidentifikasi tipe relasi,
c.
mengidentifikasi dan mengasosiasikan atribut dengan entitas atau relasi,
d.
menentukan domain atribut,
e.
menentukan atribut candidate key dan primary key,
f.
mempertimbangkan konsep enhanced modeling (langkah pilihan),
g.
memeriksa model redundansi,
h.
memvalidasi model konseptual lokal terhadap transaksi pengguna, dan
i.
meninjau model data konseptual lokal dengan pengguna.
27
2.1.7.2
Perancangan Basis Data Logikal
Menurut Connolly dan Begg (2010, p419), perancangan basis data logikal
adalah proses untuk membuat sebuah rancangan informasi yang digunakan dalam
perusahaan berdasarkan suatu model data spesifik, tetapi masih bebas dari DBMS
dan pertimbangan-pertimbangan fisik lainnya.
Menurut Connolly dan Begg (2010, p323), langkah dalam perancangan
basis data logikal yaitu :
Langkah kedua adalah membangun dan memvalidasi model data logikal
lokal untuk setiap tampilan. Langkah ini memiliki langkah selanjutnya yaitu :
a.
menghilangkan fitur yang tidak sesuai dengan model relasional (langkah
pilihan),
b.
membuat relasi untuk model data logikal lokal,
c.
memvalidasi relasi menggunakan normalisasi,
d.
memvalidasi relasi terhadap transaksi pengguna,
e.
menentukan batasan integritas, dan
f.
meninjau model data logikal lokal dengan pengguna.
Langkah ketiga adalah membangun dan memvalidasi model data logikal
global. Langkah ini memiliki langkah selanjutnya yaitu :
a.
menggabungkan model-model data logikal lokal menjadi model global,
b.
memvalidasi model data logikal global,
c.
memeriksa pertumbuhan di masa depan, dan
d.
meninjau model data logikal global dengan pengguna.
28
2.1.7.3
Perancangan Basis Data Fisikal
Menurut Connolly dan Begg (2010, p324), perancangan basis data fisikal
adalah proses menghasilkan sebuah deskripsi dari implementasi basis data pada
media penyimpanan sekunder, dengan menggambarkan hubungan dasar, berkas
organisasi dan indeks digunakan untuk memperoleh akses efisien terhadap data,
beserta batasan integritas yang terkait dan pertimbangan keamanan.
Menurut Connolly dan Begg (2010, p419), langkah dalam perancangan
basis data logikal yaitu :
Langkah keempat adalah menerjemahkan model data logikal global untuk
tujuan DBMS. Langkah ini memiliki langkah selanjutnya yaitu merancang relasi
dasar, merancang representasi derived data, dan merancang batasan perusahaan.
Langkah kelima adalah merancang representasi fisikal. Langkah ini
memiliki langkah selanjutnya yaitu menganalisis transaksi, memilih organisasi
file, memilih index, dan mengestimasi kapasitas penyimpanan yang dibutuhkan.
Langkah keenam adalah merancang user views. Langkah ketujuh adalah
merancang
mekanisme
keamanan
data.
Langkah
kedelapan
adalah
mempertimbangkan pengenalan pengendalian redundansi. Langkah yang
terakhir yaitu langkah kesembilan adalah memantau dan menyesuaikan sistem
operasional.
29
2.2 Teori-Teori Khusus
Pembahasan pada teori khusus adalah pembahasan yang berhubungan
dengan topik yang dibahas pada pembuatan skripsi.
2.2.1
Definisi Penjualan
Menurut Westwood (2011, p4), penjualan adalah konsep lugas yang
diantaranya berupa usaha membujuk pelanggan untuk membeli sebuah produk.
2.2.2
Definisi Persediaan
Menurut Kerber dan Dreckshage (2011, p108), persediaan adalah stok
barang yang digunakan untuk mendukung produksi, mendukung aktivitas, dan
juga untuk melayani pelanggan.
Menurut Rudianto (2006, p16-17), ada tiga jenis persediaan :
a.
Persediaan Bahan Baku
Bahan dasar yang menjadi komponen utama dari suatu produk.
b.
Persediaan Barang dalam Proses
Bahan baku yang telah diproses untuk diubah menjadi barang jadi, tetapi
sampai pada akhir suatu periode tertentu, belum selesai proses produksinya.
c.
Persediaan Barang Jadi
Bahan baku yang telah diproses menjadi produk jadi yang siap pakai dan
siap dipasarkan.
30
2.2.3
Unified Modeling Language (selanjutnya disingkat UML)
Menurut Lano (2009, p98), UML adalah sesuatu yang dirancang untuk
menjadi sebuah penambahan melalui penggunaan definisi profil dan streotypes
baru di dalam sebuah metamodel.
2.2.3.1
Class Diagram
Menurut Biafore (2007, p424), class diagram menunjukkan sistem dari
kelas-kelas, termasuk operasi-operasi yang dilakukan, atribut-atribut, dan
hubungan timbal balik. Biasanya digunakan untuk beberapa tujuan, termasuk
eksplorasi konsep domain model, analisis kebutuhan, atau presentasi detail desain
perangkat lunak berorientasi objek.
Pada Gambar 2.7, titik panah segitiga dari satu jenis diagram untuk langkah
umum atau lebih abstrak tipe diagram. Jenis diagram yang lebih rendah adalah
sejenis diagram yang lebih tinggi. Sehingga diagram kelas adalah semacam
diagram struktural, yang merupakan jenis diagram. Diagram juga menggunakan
panah putus-putus untuk mengindikasikan ketergantungan. Beberapa diagram
menggunakan kembali fitur-fitur yang lain dan tergantung pada definisi mereka.
Salah satu contohnya adalah diagram gambaran interaksi tergantung pada
diagram aktivitas untuk banyak notasinya.
31
Gambar 2.7 Class Diagram
32
2.2.3.2
Object Diagram
Menurut Swain (2010, p89), object diagram adalah diagram yang
menunjukkan satu set objek dan masing-masing relasinya pada saat satu waktu.
Secara grafik, object diagram adalah kumpulan simpul dan busur. Contoh dari
object diagram dapat dilihat pada Gambar 2.8.
Gambar 2.8 Object Diagram
33
2.2.3.3
Use Case Diagram
Menurut Biafore (2007, p424), use case diagram mengidentifikasikan
bagaimana interaksi eksternal dari aktor-aktor bersama dengan sistem untuk
menganalisis kegunaan kebutuhan sistem. Potongan representasi use case, aktoraktor dan hubungan timbal balik antara masing-masing. Contoh dari use case
diagram dapat dilihat pada Gambar 2.9.
Gambar 2.9 Use Case Diagram
34
2.2.3.4
Deployment Diagram
Menurut Biafore (2007, p425), deployment diagram menunjukkan struktur
sistem-sistem yang dikerahkan, konfigurasinya, dan penyebaran perangkat keras
serta komponen-komponen perangkat lunak. Dan juga digunakan sebagai high
level arsitektur model. Contoh dari deployment diagram dapat dilihat pada
Gambar 2.10.
Gambar 2.10 Deployment Diagram
35
2.2.3.5
Sequence Diagram
Menurut Biafore (2007, p424), sequence diagram menunjukkan klasifikasi,
termasuk kelas, objek, komponen, dan use case yang berpartisipasi di dalam
interaksi, di dalam urutan, dan waktunya untuk menghasilkan apa yang
dikerjakan. Sequence diagram membantu mengeksplorasi potensi penggunaan
dari sistem untuk menentukan kompleksitas kelas-kelas, dan untuk mendeteksi
potensial kemacetan sistem berorientasi objek. Contoh dari sequence diagram
dapat dilihat pada Gambar 2.11.
Gambar 2.11 Sequence Diagram
36
2.2.3.6
Collaboration Diagram
Menurut Biafore (2007, p424), collaboration diagram adalah tipe diagram
yang menggambarkan bagaimana objek berkomunikasi. Menunjukkan contoh
dari kelas-kelas, hubungan timbal balik antara kelas-kelas, dan pertukaran pesanpesan saat interaksi berlangsung. Contoh dari collaboration diagram dapat dilihat
pada Gambar 2.12.
Gambar 2.12 Collaboration Diagram
37
2.2.3.7
Activity Diagram
Menurut Biafore (2007, p424), activity diagram adalah sama dengan
flowchart dan diagram aliran data di dalam struktur pengembangan, diagram
tersebut menunjukkan proses bisnis yang high level, termasuk aliran data, atau
membantu model logika kompleks di dalam sistem.
Sedangkan menurut Mills et. al. (2010, p98), activity diagram menawarkan
tipe operasi yang sama dengan diagram lainnya selain yang tidak dapat kita
gunakan simbolnya pada activity diagram.
Gambar 2.13 menunjukkan activity diagram. Oval mewakili sebuah
aktivitas, persegi panjang dengan sudut membulat mewakili keadaan menunggu,
dan panah mewakili keadaan transisi.
Gambar 2.13 Activity Diagram
38
2.2.3.8
Component Diagram
Menurut Biafore (2007, p425), component diagram adalah diagram yang
mendeskripsikan komponen di dalam aplikasi, sistem, atau perusahaan, dan juga
komponen hubungan timbal balik, interaksi-interaksi, serta antarmuka publik.
Dan juga sebagai high level arsitektur model.
Sedangkan menurut Farrell (2011, p573-574), component diagram
digunakan ketika penulis ingin menekankan berkas, tabel basis data, dokumen,
dan komponen lain yang perangkat lunak sistem gunakan. Penulis menggunakan
diagram penyebaran ketika penulis ingin fokus pada perangkat keras sistem.
Diagram profil yang digunakan untuk memperluas model UML untuk suatu
domain tertentu. Contoh component diagram dapat dilihat pada Gambar 2.14.
Gambar 2.14 Component Diagram
39
2.2.3.9
State Diagram
Menurut Huda dan Bunafit Komputer (2010, p141), state diagram
menggambarkan transisi dan perubahan keadaan suatu objek, akibat dari
dorongan atau input yang diterimanya. Keadaan digambarkan berbentuk segi
empat dengan sudut membulat dan memiliki nama sesuai kondisinya. Transisi
antar keadaan umumnya memiliki kondisi yang merupakan syarat terjadinya
transisi yang bersangkutan. Contoh state diagram dapat dilihat pada Gambar 2.15
berikut ini.
Gambar 2.15 State Diagram
40
2.2.4
SQL Server Management Studio
Menurut Wahana Komputer (2010, p40), SQL Server Management Studio
adalah program yang dibuat oleh Microsoft untuk membantu pengguna maupun
admin dalam melakukan tugas-tugas yang berhubungan dengan server basis data.
2.2.5
Visual Basic .Net (selanjutnya disingkat Vb.NET)
Menurut Schlesinger (2008, p2), VB.Net adalah berorientasi kepada objek
bahasa dengan fitur penting. Selain itu, vb.net memiliki lingkungan
pengembangan interaktif yang menyederhanakan pengembangan bentuk-bentuk
windows untuk ditampilkan di layar.