SISTEM INFORMASI JUAL BELI DAN MANAJEMEN GUDANG DI TOKO AF.

(1)

TUGAS AKHIR

Diajukan Oleh :

Yusr il Ar ief

NPM : 0835010053

PROGAM STUDI SISTEM INFORMASI

FAKULTAS TEKNOLOGI INDUSTRI

UNIVERSITAS PEMBANGUNAN NASIONAL “VETERAN”

J AWA TIMUR

2012

Hak Cipta © milik UPN "Veteran" Jatim :

(2)

SISTEM INFORMASI J UAL BELI DAN MANAJ EMEN GUDANG DI

TOKO AF

Disusun Oleh :

YUSRIL ARIEF NPM. 0835010053

Telah disetujui untuk mengetahui Ujian Negar a Lisan

Gelombang VI Tahun Akademik 2012/2013

Pembimbing I,

Ketua Pr ogr am Studi Sistem Infor masi

Univer sita s Pembangunan Nasional “Veteran” J awa Timur

Nur Cahyo Wibowo, S.Kom, M.Kom NPT. 279030440197

(3)

SISTEM INFORMASI J UAL BELI DAN MANAJ EMEN GUDANG DI

TOKO AF

Disusun Oleh :

YUSRIL ARIEF NPM. 0835010053

Telah diper tahankan dan diter ima oleh Tim Penguji Skr ipsi

Pr ogram Studi Sistem Infor masi, Fakultas Teknologi Industr i

Univer sita s Pembangunan Nasional “Veteran” J awa Timur

Pada Tanggal 31 J uli 2012

Tim Pembimbing,

Dekan Fakultas Teknologi Industr i

Univer sitas Pembangunan Nasional “Veter an J awa Timur

Ir. Sutiyono,M.T.

Pr iza Pandunata, S.Kom, M.Sc NPT. 283010640212

(4)

ii

Salam sejahtera untuk kita semua dan semoga selalu dalam lindungan-Nya.

Puji dan syukur penulis ucapkan kepada Alloh SWT yang telah melimpahkan

rahmat-Nya kepada penulis sehingga dapat menyelesaikan Tugas Akhir ini.

Adapun judul Tugas Akhir ini adalah “Sistem Infor masi J ual Beli Dan

Manajemen Gudang Di Toko AF” dengan studi kasus di Toko Sembako AF

daerah Desa Kemasan RT 03 RW 01 Kecamatan Krian Kabupaten Sidoarjo

Pada kesempatan kali ini, penulis menyampaikan ucapan terima kasih

yang sebesar - besarnya kepada semua pihak yang telah membantu dan

memberikan dukungannya sehingga Tugas Akhir ini dapat terselesaikan. Ucapan

terima kasih penulis sampaikan kepada :

1. Ayah dan Ibu yang telah memberikan dukungan, nasihat, serta doanya.

2. Bapak Ir. Sutiyono, MT, selaku Dekan Fakultas Teknologi Industri

Universitas Pembangunan Nasional “Veteran” JawaTimur.

3. Bapak Nur Cahyo Wibowo, S.Kom, M.Kom, selaku Ketua Program Studi

Sistem Informasi.

4. Meisya Ardhi selaku pemilik toko yang dijadikan tempat studi kasus.

5. Bapak Moch. Irwan Afandi, ST, MSc, selaku Dosen Pembimbing I penulis.

6. Priza Pandunata, S,Kom, selaku Dosen Pembimbing II.

7. Semua teman-teman Program Studi Sistem Informasi angkatan 2008 UPN

“Veteran” JawaTimur.

8. Dwi Hastuti yang selalu memberikan semangat dan dukungan dalam

mengerjakan tugas akhir ini.

9. Serta seluruh pihak yang telah memberikan kontribusinya sehingga penulis

dapat menyelesaikan Tugas Akhir ini.

Semoga Buku Tugas Akhir ini memberikan manfaat dan wawasan kita

semua. Amin.

Surabaya, 31 Juli 2012

Penulis

(5)

iii

1.6 Sistematika Penulisan ... 5

BAB II LANDASAN TEORI

(6)

iv

2.8 Arsitektur Model View Controller (MVC)... 36

BAB III ANALISIS DAN PERANCANGAN SISTEM 3.1 Identifikasi Permasalahan ... 39

3.2 Perancangan Sistem ... 40

3.2.1 Use Case Diagram ... 40

(7)

v

4.1 Instalasi Aplikasi ... 75

4.1.1 Kebutuhan Perangkat Keras ... 75

4.1.2 Kebutuhan Perangkat Lunak ... 75

4.2 Implementasi Aplikasi... 76

4.2.1 Halaman Login ... 76

4.2.19 Halaman Cari Barang(Transaksi Penjualan) ... 89

(8)

vi

4.2.22 Halaman Cari Barang (TransaksiPenjualan) ... 92

4.2.23 Halaman Detail Transaksi Pembelian ... 92

4.2.24 Halaman Economic Order Quantity ... 93

4.2.25 Halaman Reorder Point ... 94

4.2.26 Halaman Lihat Stok Barang Habis ... 95

4.2.27 Halaman Cetak Laporan ... 96

4.2.28 Halaman Pembuatan Grafik ... 99

BAB V PENUTUP 5.1 Kesimpulan ... 100

5.2 Saran ... 100

DAFTAR PUSTAKA ... 101

(9)

vii

Gambar 2.1. Use Case Diagram ... 16

Gambar 2.2. Activity Diagram ... 17

Gambar 2.3. Sequence Diagram ... 18

Gambar 2.4. Class Diagram ... 20

Gambar 2.5. Statechart Diagram ... 22

Gambar 2.6. Component Diagram ... 23

Gambar 2.7. Deployment Diagram ... 24

Gambar 2.8. Arsitektur Client Server ... 33

Gambar 2.9. Arsitektur JSP ... 35

Gambar 2.10. Model 1 ... 37

Gambar 2.11. Model 2 ... 38

Gambar 3.1. Usecase Diagram Data Toko ... 41

Gambar 3.2. Usecase Diagram Transaksi Pembelian ... 43

Gambar 3.3. Usecase Diagram Transaksi Penjualan ... 43

Gambar 3.4. Activity Diagram Simpan Jenis Barang ... 43

Gambar 3.5. Activity Diagram Ubah Data JenisBarang ... 45

Gambar 3.6. Activity Diagram Simpan Data Suplier... 46

Gambar 3.7. Activity Diagram Ubah Data Suplier ... 47

Gambar 3.8. Activity Diagram Simpan Data Barang... 48

Gambar 3.9. Activity Diagram Ubah Data Barang ... 49

Gambar 3.10. Activity Diagram MenghitungEOQ ... 50

Gambar 3.11.Activity Diagram Hitung ROP... 51

Gambar 3.12. Activity Diagram Penjualan ... 52

Gambar 3.13. Activity Diagram TransaksiPembelian ... 53

Gambar 3.14.Sequence Diagram Simpan Data JenisBarang ... 54

Gambar 3.15. Sequence Diagram Ubah Data JenisBarang... 55

Gambar 3.16. Sequence Diagram SimpanSuplier ... 56

Gambar 3.17. Sequence Diagram Ubah Data Suplier ... 57

Gambar 3.18. Sequence Diagram Simpan Data Barang ... 58

Gambar 3.19. Sequence Diagram Ubah Data Barang ... 59

(10)

viii

Gambar 3.22. Sequence Diagram HitungEOQ ... 62

Gambar 3.23. Sequence Diagram Hitung ROP ... 63

Gambar 3.24. Class Diagram ... 64

Gambar 4.1. Halaman Login ... 76

Gambar 4.2. Halaman Admin ... 77

Gambar 4.3. Halaman Kasir ... 77

Gambar 4.4. Halaman Data Master ... 78

Gambar 4.5. Halaman Data JenisBarang ... 79

Gambar 4.6. Halaman Simpan Data Jenis Barang ... 79

Gambar 4.7. Halaman Cari Data Jenis Barang ... 80

Gambar 4.8. Halaman Ubah Data Jenis Barang ... 81

Gambar 4.9. Halaman Supplier ... 82

Gambar 4.10. Halaman Simpan Data Suplier ... 82

Gambar 4.11. Halaman Cari Data Nama Suplier ... 83

Gambar 4.12. Halaman Ubah Data Suplier ... 83

Gambar 4.13. Halaman Barang ... 84

Gambar 4.14. Halaman Simpan Data Barang ... 85

Gambar 4.15. Halaman Cari Data Nama Barang ... 86

Gambar 4.16. Halaman Ubah Data Jenis Barang ... 86

Gambar 4.17. Halaman Transaksi ... 87

Gambar 4.18. Halaman Transaksi Jual ... 88

Gambar 4.19. Halaman Transaksi Cari Data Barang ... 89

Gambar 4.20. Halaman Transaksi Detail Penjualan ... 90

Gambar 4.21. Halaman Cari Data Barang ... 90

Gambar 4.22. Halaman Transaksi Pembelian ... 91

Gambar 4.23. Halaman Cari Barang Transaksi Pembelian... 92

Gambar 4.24. Halaman Detail Transaksi Beli ... 92

Gambar 4.25. Halaman Transaksi Pembelian Barang ... 93

Gambar 4.26. Halaman Manajemen EOQ ... 93

Gambar 4.27. Halaman Simpan EOQ ... 94

(11)

ix

Gambar 4.30. Halaman Lihat Stok Barang Habis ... 96

Gambar 4.31. Halaman Cetak Laporan... 96

Gambar 4.32. Laporan Total Harga Perbulan ... 97

Gambar 4.33. Laporan Total Harga Perbulan ... 98

Gambar 4.34. Halaman Pembuatan Grafik ... 99

Gambar 4.35. Grafik ... 99

(12)

x

Tabel 3.1.Class Jenis Barang ... 65

Tabel 3.2.Class Supplier ... 65

Tabel 3.3.Class Barang ... 66

Tabel 3.4.Class Pengguna ... 67

Tabel 3.5.Class Penjualan ... 67

Tabel 3.6.Class Pembelian ... 68

Tabel 3.7.Spesifikasi Tabel Jenis Barang ... 69

Tabel 3.8.Spesifikasi Tabel Supplier ... 69

Tabel 3.9.Spesifikasi Tabel Barang ... 70

Tabel 3.10.Spesifikasi Tabel Pengguna ... 71

Tabel 3.11.Spesifikasi Tabel Penjualan ... 72

Tabel 3.12.Spesifikasi Tabel Detail Penjualan ... 72

Tabel 3.13.Spesifikasi Tabel Pembelian ... 73

Tabel 3.14.Spesifikasi Tabel Detail Pembelian ... 73

(13)

Studi Kasus : TokoSembako AF

---

i ABSTRAKSI

Manajemen Gudang atau bisa disebut manajemen persediaan adalah cara

memanajemen gudang dimana barang – barang di gudang tersebut diawasi jumlah

stoknya menggunakan rumus Economic Order Quantity dan Reorder Point.

Dengan mengamati data – data penjualan dan barang akan diperoleh harga jual

barang, jumlah kebutuhan barang selama 1 periode, dll, maka hasil pengamatan

tersebut dapat menjadi masukan – masukan atau inputan yang dapat dimanfaatkan

untuk perhitungan kedua rumus tersebut. Hasil dari perhitungan tersebut akan

digunakan sebagai patokan untuk memesan jumlah barang yang paling ekonomis.

Hal ini sangat bermanfaat untuk mencari biaya paling hemat. Hasil – hasil

masukan tersebut juga akan menghasilkan sebuah variabel dimana variabel

tersebut dapat digunakan sebagai patokan oleh pemilik toko untuk memesan

barang kembali. Kedua rumus tersebut saling berkaitan. Jika sistem ini hanya

menggunakan rumus Economic Order Quantity saja maka aplikasi ini kurang

begitu berfungsi karena user hanya mengetahui jumlah ekomonis barang sekali

pesan. Oleh karena itu variabel ini harus diolah lagi agar mendapat hasil yang

maksimal.

Kata Kunci :Sistem manajemen persediaan, Economic Order Quantity, Reorder

Point.

(14)

BAB I

PENDAHULUAN

1.1 Latar Belaka ng Masalah

Salah satu elemen penting dalam sebuah toko adalah manajemen

gudang dan transaksi jual belinya. Gudang adalah sebuah ruangan yang

digunakan untuk menyimpan berbagai macam barang dan fungsi gudang

pada toko sangat berarti, yaitu untuk tempat menyimpan stok-stok barang

yang akan dijual agar transaksi jual beli dapat terus berlangsung. Jika

transaksi dapat terus berlangsung, maka pelanggan tidak dikecewakan.

Manajemen persediaan pada gudang umumnya masih menggunakan

proses manual. Proses manual sangat tidak cepat dan membutuhkan tenaga

serta ketelitian dalam manajemenya. Transaksi beli adalah proses barang

masuk ke gudang dari suplier ke toko. Transaksi beli perlu dicatat agar

dapat mengetahui barang apa saja yang dibeli pada periode harian, bulanan

atau tahunan. Transaksi jual adalah proses barang keluar dari toko ke

konsumen. Di sini sangat perlu dicatat, hasil catatan tranksaksi ini bisa

dipakai untuk laporan harian, bulanan, tahunan atau untuk mengetahui

barang apa saja yang paling sering terjual.

Toko AF adalah sebuah toko yang menjual sembako dan keperluan

rumah tangga. Toko ini terletak di daerah Desa Kemasan Rt 03 Rw 01

Kecamatan Krian Kabupaten Sidoarjo. Dalam memanajemen transaksi jual

beli dan stoknya. Terkadang pemilik toko AF ini tidak mengetahui tanggal

kadaluarsa suatu barang, sisa stok barang, waktu pemesanan barang

(15)

sehingga kehabisan stok sangat sering terjadi dan itu membuat pelanggan

pindah ke toko lain.

Berdasarkan hal di atas, maka perlu dibuat sistem informasi jual

beli dan manajemen gudang di Toko AF. Aplikasi ini berbasis web dengan

ruang lingkup jarigan pribadi atau intranet. Dalam memanajemen

gudangnya, sistem ini menggunakan dua metode EOQ dan Reorder Point.

Produk dengan kebutuhan yang bersifat independen seperti pada

sistem jasa pertokoan yang menjual produk jadi atau menjual komponen

akan menggunakan pengendalian persediaan yang biasa disebut sistem

persediaan jumlah pemesanan ekonomis setiap kali pesan(EOQ) sehingga

meminimalisasi biaya total persediaan. Metode yang kedua adalah Reorder

Point (ROP). Pada dasarnya metode ROP merupakan suatu teknik

pengisian kembali inventori apabila real stock in-hand plus on order jatuh

atau berada di bawah titik pemesanan kembali (Reorder Point = ROP).

ROP merupakan metode inventori yang menempatkan suatu pesanan untuk

lot tertentu apabila kuantitas on-hand berkurang sampai tingkat yang

ditentukan terlebih dahulu yang dikenal sebagai titik pemesanan kembali

(ROP). Implementasi ROP membutuhkan mekanisme yang (memberi

tanda) manajemen bilamana ROP telah tercapai.

Di dalam sistem terdapat manajemen inventori dimana data-data

yang di peroleh meliputi jumlah pemakaian pertahun, biaya pemesanan,

presentasi penyimpanan biaya barang, holding cost, jumlah pemesanan,

jumlah permintaan rata-rata dan lead time akan menjadi inputan dalam

sistem ini dan dimasukan kedalam rumus Economic Order Quantity

(16)

(EOQ) yang akan menghasilkan berapa banyak barang yang dipesan setiap

kali melakukan pemesanan ke pemasok dengan harga yang paling murah.

Data tersebut juga akan digunakan sebagai masukan rumus Reorder Point

(ROP) dimana jumlah (tingkat kebutuhan) dikalikan Lead Time dan akan

menghasilkan sebuah titik dimana pesanan baru harus dilakukan untuk

persiapan dimulai.

Aplikasi yang dibuat diharapkan dapat membantu proses

manajemen di toko tersebut yang masih manual agar dapat lebih

menghemat waktu, tenaga dan lebih akurat dengan asumsi aplikasi ini

hanya dapat dipakai di satu toko dan toko ini hanya mempunyai 1 gudang.

1.2 Per umusan Masalah

1. Bagaimana mencatat transaksi jual beli dengan sistem berbasis

komputer.

2. Bagaimana memeriksa stok agar lebih baik dan terintregasi.

3. Bagaimana mencatat data – data barang dengan sistem berbasis

komputer.

1.3 Batasan Masalah

Dalam pembuatan sistem ini terdapat beberapa hal yang menjadi

batasan masalah. Adapun batasan masalah tersebut adalah sebagai berikut :

1. Ruang lingkup sistem hanya mengelola transaksi jual beli dan

manajemen gudang di Toko AF.

2. Aplikasi ini hanya membahas seputar pencatatan transaksi

(17)

penjualan, pencatatan transaksi pembelian dan fitur manajemen

gudang menggunakan metode EOQ dan Reorder Point.

3. Tidak membahas masalah keamanan data.

4. Tidak membahas solusi apabila ada kerusakan perangkat keras yang

menyebabkan aplikasi ini tidak berjalan.

5. Aplikasi ini menggunakan struktur jaringan pribadi atau intranet.

6. Aplikasi ini hanya bisa digunakan untuk satu gudang sesuai

permasalahan ditempat studi kasus.

7. Pada transaksi penjualan, aplikasi ini hanya mencatat barang yang

terjual dan total harga setiak satu kali transaksi saja.

8. Pada transaksi pembelian, aplikasi ini hanya mencatat barang

masuk dan total harga setiap satu kali transaksi saja.

9. Aplikasi ini hanya digunakan oleh pemilik atau pegawai di Toko

AF saja.

10.Rumus EOQ hanya bisa digunakan pada 1 barang saja.

11.Aplikasi ini hanya mengambil bagian manajemen persediaan atau

inventorinya saja.

1.4 Tujuan

Tujuan dari tugas akhir ini adalah menyelesaikan permasalahan di

Toko AF yaitu manajemen transaksi jual beli dan manajemen gudang

dengan membuat aplikasi yang bisa mengatasi atau menyelesaikan

permasalahan tersebut secara cepat menggunakan metode EOQ dan

Reorder Point.

(18)

1.5 Manfaat

Aplikasi pencatatan jual beli dan manajemen gudang ini akan

membantu pemilik Toko AF dalam mencatat dan memanajemen transaksi

jual beli dan memanajemen gudangnya. Hal ini secara tidak langsung akan

memberikan manfaat kepada pemilik Toko AF karena setiap transaksi akan

dicatat secara sistematis dan pemilik akan mudah melihat hasil-hasil

laporan dari pengolahan data pencatatan transaksi jaul beli tersebut. Selain

itu, pemilik toko akan lebih mudah mengetahui barang yang akan

kadaluarsa atau barang yang sudah waktunya stok kembali.

1.6 Sistematika Penulisan

Sistem penulisan tugas akhir ini disusun kedalam lima bab. Adapun

penjabarang dari kelima bab tersebut adalah sebagai berikut :

BAB I : PENDAHULUAN

Pada bab ini membahas mengenai latar belakang masalah,

perumusan masalah, batasan masalah, tujuan yang hendak dicapai,

manfaat dari sistem ini dan sistematika penulisan tugas akhir.

BAB II : LANDASAN TEORI

Pada bab ini dibahas tentang metode Economic Order Quantity

(EOQ) dan Reorder Point (ROP), proses perhitungan metode (EOQ) dan

(ROP), profil Toko AF sebagai tempat studi kasus, aplikasi web, Java

Server Page (JSP), Object Oriented, arsitektur Model View Controller.

(19)

BAB III : ANALISIS DAN PERENCANAAN SISTEM

Dalam bab in terdapat identifikasi masalah dan perancangan sistem

menggunakan Waterfall model menurut Pressman dimulai dair analysis,

design system, code, test. Tahap design system menggunakan diagram

UML sampai diagram class. Tahap code menggunakan HTML, JSTL dan

JSP.

BAB IV : IMPLEMENTASI DAN UJI COBA SISTEM

Dalam bab ini akan dijelaskan mengenai kebtuhan perangkat keras

maupun perangkat lunak serta output dari aplikasi ini, termasuk penjelasan

tentang penggunaan aplikasi Serta dilakukannya uji coba aplikasi yang

telah dibuat. Proses uji coba akan menguji output yang dihasilkan, apakah

telah sesuai denga tujuan yang telah ditentukan.

BAB V : PENUTUP

Pada bab ini berisi kesimpulan terhadap aplikasi yang telah dibuat

serta saran bagi pengembangan sistem selanjutnya.

(20)

BAB II

LANDASAN TEORI

2.1 Toko AF

Toko AF adalah sebuah toko sembako di daerah Desa Kemasan Rt

03 Rw 01 Kecamatan Krian Kabupaten Sidoarjo.Toko ini menjual

berbagai peralatan rumah tangga, bahan pokok dan sebagainya.Toko ini

mempunyai satu gudang kecil untuk menyimpan stok barang sebelum

dikeluarkan atau dijual. Semua proses bisnis di Toko AF masih

manual, mulai dari mencatat transaksi penjualan barang, pembelian

barang, dan pencatatan data-data di gudang masih manual.

2.2 Esensi Gudang

Produk atau bahan baku yang disimpan untuk mengantisipasi

fluktuasi membutuhkan sebuah fasilitas penyimpanan. Fasilitas

penyimpanan ini dikenal dengan gudang. Gudang berfungsi sebagai

penunjang kegiatan utama pabrik. Gudang dapat didefinisikan sebagai

sebuah fasilitas yang berfungsi untuk menyimpan barang yang akan

digunakan dalam produksi atau penjualan. Jumlah barang yang disimpan

di dalam gudang sesuai dengan kebijakan persediaan untuk setiap jenis

barang. Dalam hal ini fungsi gudang bisa berorientasi pada kegiatan

produksi ataupun penjualan. Gudang sebagai penunjang kegiatan produksi

berisikan bahan baku, bahan penolong, dan bahan tambahan; sedangkan

sebagai penunjang penjualan berisikan produk-produk jadi yang siap

(21)

dipasarkan. Secara luas, gudang tidak harus berada dilingkungan pabrik

karena pusat-pusat distribusi juga memiliki gudang. Penjelasan gudang

dalam hal ini akan difokuskan pada keberadaanya di lingkungan pabrik.

Baik itu untuk penyimpanan bahan maupun produk akhir (Hadiguna, Rika

Ampuh,2009).

Sebagaimana sudah dijelaskan di atas, pada suatu pabrik

kategorisasi gudang dapat dibedakan menurut karakteristik barang yang

akan disimpan, yaitu penyimpanan bahan baku, penyimpanan barang

setengah jadi dan penyimpanan produk jadi. Sebagai tempat penyimpanan

bahan baku berarti gudang akan menyimpan setiap bahan yang dibutuhkan

atau akan digunakan untuk kelancaran proses produksi (Hadiguna, Rika

Ampuh,2009).

2.3 Economic Order Quantity

Dalam sistem produksi, ada 2 jenis kebutuhan berdasarkan

hubungan dengan komponen lainya, yaitu kebutuhan tak tergantung

(independent) dan kebutuhan (independent demand) bila kebutuhan untuk

suatu sistem (komponen) tidak ada hubunganya dengan item yang lain.

Kebutuhan tak tergantung biasanya menunjukan pola yang berlanjut

tetapi berfluktuasi karena pengaruh acak dari pasar, seperti produk jadi

dan suku cadang (Vincent Gasperz, 2004).

(22)

Kebutuhan disebut tergantung (dependent demand) bila ada

hubungan langsung antara suatu item (komponen) dengan item - item lain

pada level yang lebih tinggi (parent item). Kebutuhan untuk item-item

yang bersifat dependent merupakan hasil dari kebutuhan yang disebabkan

oleh penggunaan item-item tersebut dalam memproduksi item yang lain,

seperti dalam kasus di mana bahan baku dan komponen asembling yang

digunakan dalam membuat produk jadi. Sebagai contoh, ada

hubungan “tiga untuk satu” antara roda dan becak. Jadi permintaan untuk

produk akhir (becak) mungkin kontinyu dan independent, tetapi

permintaan untuk level yang lebih rendah, yaitu roda becak cenderung

bersifat dependent (Vincent Gasperz, 2004).

Dependent demand tidak terjadi secara acak, tetapi terjadi lumpy.

Keadaan lumpy ini berasal dari penerapan jadwal produksi yang

berdasarkan lot - lot. Meskipun item - item yang bersifat independent dibutuhkan secara kontinyu, item-item tersebut lebih ekonomis bila

diproduksi secara lot. Sejumlah tertentu item-item yang dibutuhkan

untuk memproduksi suatu lot produk jadi biasanya diambil dari

persediaan sekaligus, di mana pengambilan ulang baru dilakukan lagi bila

kita memproduksi lot yang lain (Vincent Gasperz, 2004).

Adanya 2 jenis kebutuhan tersebut mengakibatkan pengendalian

persediaan untuk masing-masing jenis produk menjadi berbeda. Produk

dengan kebutuhan yang bersifat independen seperti pada sistem jasa

pertokoan yang menjual produk jadi atau menjual komponen akan

menggunakan pengendalian persediaan yang biasa disebut sistem

(23)

persediaan jumlah pesanan ekonomis (Economic Order Quantity =

EOQ) (Vincent Gasperz, 2004).

Model statis EOQ memakai asumsi - asumsi sebagai berikut

(Vincent Gasperz, 2004):

1. Hanya satu item barang (produk) yang diperhitungkan.

2. Kebutuahan (permintaan) setiap periode diketahui (tertentu).

3. Barang yang dipesan diasumsikan dapat segera tersedia

(instaneously) atau tingkat produksi (production rate) barang yang

dipesan berlimpah (tak terhingga).

4. Waktu ancang - ancang (lead time) bersifat konstan.

5. Setiap pesanan diterima dalam sekali pengiriman dan langsung

dapat digunakan.

6. Tidak ada pesanan ulang (back order) karena kehabisan persediaan

(shortage).

7. Tidak ada diskon untuk jumlah pembelian yang banyak (quantity

discount).

Dari asusmsi-asumsi di atas, model ini mungkin diaplikasikan baik

pada sistem manufaktur seperti penentuan persediaan bahan baku dan

pada sistem non manufaktur seperti pada penentuan jumlah bola lampu

pada suatu bangunan, penggunaan perlengkapan habis pakai (office

supplies) seperti kertas,buku nota dan pensil, konsumsi bahan makanan

seperti beras, jagung, dan lain – lain (Vincent Gasperz, 2004).

(24)

Tujuan model ini adalah untuk menentukan jumlah ekonomis

setiap kali pemesanan (EOQ) sehingga meminimalisasi biaya total

persediaan, dimana (Vincent Gasperz, 2004):

Q = √2 * D* k / h

keterangan:

Q = Jumlah (kuantitas) pesanan (unit).

D = Jumlah kebutuhan barang selama satu periode(misalnya: 1 tahun).

k = ordering cost setiap kali pesan.

H = Holding cost = c * i

i = Prosentase biaya penyimpanan pertahun dari nilai barang

c = purchasing cost per satuan nilai persediaan

Variabel D adalah jumlah pemakaian per tahun dan bisa di lihat

dari histori atau data-data penjualan selama setahun.Variabel k adalah biaya pemesanan setiap pemesanan, variabel ini tidak ada rumus pasti

untuk menentukan nilainya, bisa dilihat dari biaya operasional dalam

melakukan pemesanan barang. Variabel i adalah variabel presentasi

biaya penyimpanan per tahun dari nilai barang (%). Hal - hal yang

mempengaruhi penyimpanan adalah tanggal expired barang, tingkat

kesulitan pengadaan dan jenis barang. Biaya simpan tinggi agar dia tidak

menyimpan, semakin tinggi biaya simpan resiko barang tersebut semakin

besar. Tidak ada rumus pasti untuk menentukan persentasi biaya

penyimpanan, harus ditentukan oleh pemilik toko dan diambil dari

beberapa persen harga barang. Untuk toko sembako tempat studi kasus,

(25)

biaya penyimpanan cukup 5% dengan alasan toko sembako putaranya

cepat dan barang-barang di toko sembako biasanya mudah didapat.

2.4 Reorder Point (ROP)

Dalam sistem ROP setiap pusat distribusi pada tingkat lebih rendah

(store or branch warehouse) meramalkan permintaan untuk produk guna

melayani pelanggannya, kemudian memesan dari pusat distribusi pada

tingkat lebih tinggi (main warehouse) apabila kuantitas dalam stok pada

pusat distribusi yang lebih rendah itu (branch warehouse) mencapai ROP.

ROP ditetapkan untuk setiap stockkeeping unit (sku) sebagai ramalan

permintaan selama waktu tunggu pengisian panjang waktu tunggu untuk

resupply dari wholesale, atau area atau warehouse ditambahstok

pengaman. ROP dan stok pengaman ditentukan secara konvnsional.

Sistem ini dapat menghasilkan permintaan yang sangat bervariasi di pusat

distribusi pada tingkat yang lebih tinggi (central warehouse) karena hanya

memiliki interaksi yang kecil atau sedikit di antara branch warehouse dan

central warehouse, sehingga membutuhkan stok pengaman yang relatif

besar pada central warehouse di samping stok pengaman pada branch

warehouse(Vincent Gasperz, 2004).

Sistem tarik dengan ROP (pull system with order point)

menimbulkan cascading effect, yaitu: input ke setiap tingkat adalah output

dari tingkat atau tahap sebelumnya, sehingga menyebabkan

kesalingtergantungan di antara tingkat-tingkat dalam sistem distribusi.

Pada dasarnya metode ROP merupakan suatu teknik pengisian

(26)

kembali inventori apabila stock on-hand plus on-order jatuh atau berada di

bawah titik pemesanan kembali (reorder point = ROP). ROP merupakan

metode inventori yang menempatkan suatu pesanan untuk lot tertentu

apabila kuantitas on-hand berkurang sampai tingkat yang ditentukan

terlebih dahulu yang dikenal sebagai titik pemesanan kembali (ROP). ROP

dihitung berdasarkan formula(Vincent Gasperz, 2004):

ROP = DLT * SS

keterangan :

ROP = Titik Pemesanan Kembali

DLT = Permintaan selama waktu tunggu (Demand During Lead Time).

SS = Stok Pengamanan

Terdapat empat faktor yang menentukan ROP, yaitu:

1. Tingkat permintaan.

2. Waktu Tunggu.

3. Ketidakpastian dalam tingkat permintaan dan waktu tunggu

pengisian kembali.

4. Kebijaksanaan manajemen berkaitan dengan tingkat pelayanan

pelangganyang dapat diterima.

Implementasi sistem ROP membutuhkan mekanisme yang

menyiagakan (memberi tanda) manajemen bilaman ROP telah tercapai.

Terdapat dua metode untuk mencapai ini, yaitu: perpetual inventory

system dan two-bin inventory system. Two-bin system terbaik cocok untuk

dependent demand dan untuk item-item bernilai rendah dengan waktu

tunggu pendek, misalnya: office supplies dan common hardware. Two-bin

(27)

system merupakan bentuk lain yang populer dari visual review system, di

mana dua lokasi penyimpanan dipakai untuk stok iterm yang sama. Lokasi

penyimpanan dapat berupa bins, floor space, shelf space, barrels, atau

bentuk lainya. Aturan dari two-bin system adalah sederhana, yaitu: apabila

satu lokasi atau bin-system menjadi kosong, pesanan untuk pengisian

kembali dilakukan, sementara penggunaan material diambil dari bin

alternatif (kedua). Asusmsi ini tentu saja didasarkan pada bin itu berisi

jumlah stok item yang cukup untuk melayani permintaan yang diantisipasi

(anticipated demand) melalui waktu tunggu ditambah stok pengaman.

Biasanya teknik reorder point mengasumsikan bahwa metode

perpetual digunakan to keep track of inventory sehingga on-hand balance

selalu diketahui untuk mengendalikan sistem, juga digunakan untuk

continuous-demand products.

2.5 Unified Modeling Language(UML)

Notasi UML dibuat sebagai kolaborasi dari Grady Booch,

DR.James Rumbough, Ivar jacobson, Rebecca Wirfs-Brock, Peter Yourdon

dan lainya. Jacobson menulis tentang pendefinisian persyaratan

-persyaratan sistem yang disebut use case, juga mengembangkan sebuah

metode untuk perancangan sistem yang disebut Object-Oriented Software

Engineering (OOSE) yang berfokus pada analisis. Booch, Rumbough

dan Jacobson biasa disebut tiga sekawan (tree amigos). Semuanya bekerja

di Rational Software Corporation dan berfokus pada standarisasi dan

perbaikan ulang UML. Simbol UML mirip dengan Booch, notasi OMT

(28)

dan juga ada kemiripan dengan notasi lainya.

Penggabungan beberapa metode menjadi UML dimuali 1993.

Setiap orang dari tiga sekawan di rational mulai menggabungkan idenya

dengan metode-metode lainya. Pada akhir tahun 1995 Unified Method

versi 0.8 diperkenalkan. Unified method diperbaiki dan diubah menjadi

UML pada tahun 1997, dan pada tahun itu juga beberapa perusahaan

pengembang utama perangkat lunak mulai mengadopsinya.

Sebagai mana dikatakan di awal bab ini, bahwa untuk

mendapatkan banyak pandangan terhadap sistem informasi yang kana

dibangun, UML menyediakan beberapa diagram visual yang menunjukan

berbagai aspek dalam sistem. Ada beberapa diagram yang disediakan

dalam UML:

(29)

2.5.1 Use Case Diagram

Diagram use case menyajikan interaksi antara use case dan aktor.

Dimana, aktor dapat berupa orang, peralatan, atau sistem lain yang

berinteraksi dengan sistem yang dibangun. Use case menggambarkan

fungsionalitas sistem atau persyaratan - persyaratan yang harus dipenuhi

sistem dari pandangan pemakai.

Ga mbar 2.1. Usecase diagr am

Diagram use case ini menunjukan interaksi antara use case dan

aktor untuk sistem ATM. Pada contoh ini, aktor pelanggan menggunakan

beberapa use case, antara lain mentransfer uang, mendepositkan dana,

membayar kredit, menarik uang, mengganti PIN. Petugas Bank dapat

mengganti PIN pelanggan. Use case membayar kredit memberikan arah

panah ke sektor Sistem Kredit, dimana merupakan aktor berupa sistem lain

yang menerima informasi/data dari sistem ATM.

(30)

2.5.2 Activity Diagram

Diagram aktivitas atau Activity Diagram menggambarkan aliran

fungsionalitas sistem. Pada tahap pemodelan bisnis, diagram aktivitas

dapat digunakan untuk menunjukan aliran kerja bisnis (business work

flow). Dapat juga digunakan utnuk menggambarkan aliran kejadian

(flow of events).Contoh diagram aktivitas ditunjukan pada gambar 2.2,

dimana aktivitas dalam diagram dipresentasikan dengan bujur sangkar

bersudut tidak lancip, yang di dalamnya berisi langkah - langkah apa saja

yang terjadi dalam aliran kerja. Ada sebuah keadaan mulai (start state)

yang menunjukan dimulainya aliran kerja, dan sebuah keadaan selesai

(end state) yang menunjukan akhir diagram, titik keputusan

diperesentasikan dengan diamond.

Gambar 2.2. Activity diagr am

(31)

Diagram aktivitas tidak perlu dibuat untuk setiap aliran kerja, tetapi

diagram ini akan sangat berguna untuk aliran kerja yang komplek dan

melebar.

2.5.3 Sequence Diagram

Diagram sekuensial atau sequence diagram digunakan untuk

menunjukan aliran fungsionalitas dalam use case. Misalkan, dalam use

case “menarik uang” mempunyai beberapa kemungkinan, seperti

penarikan uang secara normal,percobaan penarikan uang tanpa kecukupan

kesediaan dana, penarikan dengan menggunakan PIN yang salah, dan

lainya.

Ga mbar 2.3. Sequence diagr am

(32)

2.5.4 Collaboration Diagram

Pada dasarnya diagram ini sama dengan diagram sekuensial, tetapi

orang menggunakan diagram ini untuk alasan yang berbeda. Tenaga ahli

jaminan kualitas dan arsitek sistem menggunakan diagram ini untuk

melihat proses distribusi antar objek. Diagram ini berbentuk seperti

bintang, dengan beberapa objek yang berkomunikasi dengan sebuah objek

pusat. Arsitek sistem menggunakan diagram ini untuk menyimpulkan

bahwa sistem yang dibangun terlalu tergantung pada objek pusat dan

merancang ulang objek - objek untuk mendistribusikan proses secara

merata. Interaksi demikian akan sulit dilihat jika meggunakan diagram

sekuensial saja.

2.5.5 Class Diagram

Diagram kelas atau class diagram menunjukan iteraksi antar kelas

dalam sistem. Sebagai contoh, nomor account milik Arvin adalah sebuah

objek dari kelas Account. Kelas mengandung informasi dan tingkah

laku (behavior )yang berkaitan dengan informasi tersebut. Kelas

Account mengandung nomor PIN. Sebuah kelas pada diagram kelas dibuat

untuk setiap objek pada diagram sekuensial atau diagram kolaborasi.

(33)

Gambar 2.4. Class diagram

Diagram di atas menunjukan hubungan antar kelas-kelas yang

diimplementasikan oleh use case “menarik uang”. Diagram ini terdiri atas

empat kelas: Pembaca Kartu, Account, Layar ATM dan Dispenser Tunai.

Sebuah kelas dibuat dalam bentuk bujur sangkar yang terbagi dalam tiga

bagian. Bagian pertama menunjukan nama kelas. Bagian kedua

menunjukan anggota kelas yang memuat informasi atau atribut, misalnya

pada kelas Account mempunyai tiga informasi yaitu Nomor Account, PIN

dan Saldo. Bagian ketiga menunjukan operasi-operasi dari sebuah kelas,

dimana operasi dari sebuah kelas adalah tingkah laku yang disediakan oleh

kelas. Kelas Account menyediakan 4 operasi yaitu buka, tarik dana, potong

dana dan verifikasi dana.

Garis yang menghubungkan antar kelas menunjukan hubungan

komunikasi antar kelas. Misalkan, kelas Account berhubungan dengan

(34)

kelas Layar ATM karena keduanya berhubungan langsung satu sama lain.

Kelas Pembaca Kartu dan dispenser tunai tidak berhubungan karena

keduanya tidak berkomunikasi di dalam diagram sekuensial atau di

diagram kolaborasi.

Para programer menggunakan diagram ini untuk mengembangkan

kelas. CASEtool tertentu seperti rational rose, membangkitkan struktur

kode sumber untuk kelas - kelas, kemudian para programer

menyempurnakan dengan bahasa pemrograman yang dipilih saat coding.

Para analisis menggunakan diagram ini untuk menunjukan detail sistem,

sedangkan arsitek sistem mempergunakan diagram ini untuk melihat

rancangan sistem

2.5.6 StatechartDiagram

Diagram statechart atau statechart diagram menyediakan sebuah

cara untuk memodelkan bermacam-macam keadaan yang mungkin dialami

oleh sebuah objek. Jika dalam diagram kelas menunjukan gambaran

statis dan kelas-kelas relasinya, diagram statechart digunakan untuk

memodelkan tingkah laku dinamik sistem.

(35)

Gambar 2.5. Statechar t diagr am

Diagram ini menunjukan kegiatan objek, misalkan sebuah Account

di bank dapat eksis dalam beberapa keadaan yang berbeda. Seperti dapat

buka, tutup, atau kondisi overdraw (keadaan dimana jumlah pengambilan

lebih besar dari simpanan yang ada). Pada gambar 2.5, terlihat

keadaan dimana sebuah account dapat eksis dan dapat bergerak dari usatu

keaadaan ke keadaan lainya.Misalnya, saat account berada pada kondisi

Buka dan pelanggan meminta penutupan, maka account bergerak ke

kondisi Tutup. Jika ada pada kondisi Buka dan pelanggan membuat

penarikan, account akan bergerak ke kondisi Overdrawn, jika saldo

terakhir setelah dikurangi jumlah penarikan kurang dari nol.

(36)

2.5.7 Component Diagram

Diagram komponen atau component diagram menunjukan model

secara fisik komponen perangkat lunak pada sistem dan hubunganya antar

mereka. Ada dua tipe komponendalamdiagramyaitukomponen

executable dan kode pustaka.

Masing-masing kelas dalam model akan dipetakan ke sebuah

komponen kode pustaka. Setelah komponen dibuat, mereka ditambahkan

dalam diagram komponen dengan memberikan relasi atara

komponen-komponen.Relasi yang terjadi antar komponen hanya satu tipe relasi

yaitu depedensi yang menunjukan ketergantungan compile-time dan

run-time antara komponen-komponen tersebut.

Gambar 2.6. Component diagram

(37)

Diagram komponen di gambar 2.6 memperlihatkan client dala

sistem ATM. Dalam masalah ini, tim pengembang memutuskan

membangun sistem dengan menggunakan JAVA. Setiap kelas memiliki

header dan body file sendiri. Sehingga setiap kelas dipetakan ke

komponen-komponennya sendiri di dalam diagram. Misalnya, kelas layar

ATM dipetakan ke dalam komponen Layar ATM. Kelas Layar ATM

juga dipetakan ke komponen Layar ATM yang kedua. Kedua kompnen ini

mewakili header dan body file dari kelas Layar ATM(lihat gambar 2.6).

Komponen terhubung oleh garis putus-putus yang menampilkan

hubungan depedensi antar komponen. Misalkan, pada kelas Pembaca

Kartu bergantung kepada kelas Layar ATM. Hal ini berarti bahwa kelas

Layar ATM harus tersedia saat kelas Pembaca Kartu dikompilasi. Jika

semua kelas telah dikompilasi, maka ATM.exe dibuat.

Diagram komponen digunakan oleh siapapun yang bertanggung

jawab untuk melakukan kompilasi sistem. Diagram ini juga menunjukan

komponen apa yang dibutuhkan saat proses kompilasi dan menampilkan

komonen run-time apa saja yang dibuat sebagai hasil proses

kompilasi. Komponen diagram memperlihatkan pemetaan dari

kelas-kelas ke komponen-komponen sebagai implementasi kelas-kelas.

2.5.8 Deployment Diagram

Diagram deployment atau deployment diagram menampilkan

rancangan fisik jaringan dimana berbagai komponen akan terdapat di sana.

Pada sistem ATM, terdapat banyak subsistem yang dijalankan pada

(38)

peralatan fisik yang terpisah atau sering disebut node. Diagram

deployment untuk sistem ATM diilustrasikan pada gambar 2.7

Gambar 2.7. Deployment diagr am

Diagram distribusi di gambar 2.6 menunjukan rancangan sistem

ATM. ATMClient.exe akan berjalan pada banyak lokasi yang berbeda.

ATM Client akan berhubungan melalui jaringan khusus dengan server

ATM regional. Sedangkan ATMServer.exe akan dijalankan di server

regional. Server ATM Regional terhubung melalui Local Area

Network(LAN) dengan basis data perbankan yang menggunakan

ORACLE. Printer juga terhubung pada server ATM Regional.

(39)

Dengan demikian, diagram ini memperlihatkan setup fisik sistem.

Sistem ATM menjadi arsitektur three-tier dengan one-tier masing-masing untuk basis data, server regional dan client.

Diagram deployment digunakan oleh manajer proyek, arsitek

sistem dan karyawan distribusi untuk memahami rancangan fisik sistem

dan di mana saja terdapat subsistem yang akan dibuat. Diagram ini

membantu menajer proyek mengkomunikasikan tentang apa yang sistem

ingikan terhadap pemakai, juga membantu bagian pengembangan untuk

merencanakan distribusi yang akan ditawarkan.

2.6 Konsep Sistem Untuk Ber or ientasi Objek

Berorientasi objek atau object oriented merupakan paradigma baru

dalam rekayasa perangkat lunak yang memandang sistem sebagai

kumpulan objek-objek diskrit yang saling berinteraksi. Yang

dimaksud berorientasi objek adalah bahwa mengorganisasikan perangkat

lunak sebagai kumpulan objek-objek diskrit yang bekerja sama antara

informasi atau struktur data da perilaku(behavior) yang mengaturnya. Objek adalah segala sesuatu yang ada disekitar kita, dimana

objek-objeklah yang menyusun dunia ini. Misalkan: mobil, bis, truk, motor,

becak, sepeda, dan lain-lain adalah contoh objek kendaraan. Setiap objek

mempunyai informasi atau atribut dan perilaku sebagai suatu operasi

pengaturnya. Atribut-atribut objek diatas antara lain: jumlah roda, warna,

berat, dan seterusnya. Sedangkan operasi-operasi pengatur objek di atas

adalah berjalan, belok kanan, belok kiri, naikan kecepatan, dan seterusnya.

(40)

Objek-objek yang mempunyai atribut dan operasi yang sama dapat

dikelompokan dalam sebuah kategori. Misalkan, obek mobil, bis, truk,

motor, becak, dan sepeda dapat dikelompokan ke dalam sebuah kategori

yaitu “kendaraan”. Sebuah kategori untuk beberapa objek disebut

kelas.Sejauh mana kategori dari sebuah kelas, tergantung kepada semesta

pembicaraan. Pada contoh di atas, jika Kategori kelas yang dikehendaki

adalah “kendaraan bermotor” maka objek - objek yang menjadi

anggotanya adalah mobil, bis, truk dan motor. Sedangkan objek becak dan

sepeda di luar lingkup “kendaraan bermotor” sehinngga tidak menjadi

anggota kelas.

Paradigma berorientasi objek mempunyai bidang aplikasi yang

sangat luas dalam bidang rekayasa perangkat lunak, antara lain:

pemrograman, pemodelan sistem informasi, manajemen proyek, perangkat

keras, testing dan sebagainya. Pada pemrograman berorientasi objek

didefinisikan sebagai suatu cara membuat program yang mempunyai

beberapa keuntungan. Ia menggunakan pendekatan component-based

untuk pengembangan perangkat lunak, dimana pertama kali dimulai

dengan membuat sebuah sistem yang merupakan kumpulan objek-objek.

Kemudian saat pengembangan sistem, dilakukan dengan mengembangkan

komponen-komponen ke sistem atau dengan menciptakan komponen baru

dari komponen yang sudah ada. Pada akhirnya, jika membangun sistem

baru, maka cukup dengan menggunakan kembali objek-objek yang

telah dibuat ke sistem baru yang sedang dibangun.

Beberapa isilah berorientasi objek :

(41)

1. Abstraksi(abstraction)

Abstraksi atau abstaction secara sederhana dikatakan sebagai

proses memilah beberapa atribut dan beberapa operasi suatu objek hanya

sampai pada yang benar - benar diperlukan saja, dan membuang atrribut

dan operasi tidak diperlukan untuk persoalan yang dihadapi. Tipe

persoalan yang berbeda memerlukan informasi yang berbeda.

Misalkan, sebuah program komputer dibangun untuk seorang ahli teknik

pembuat mesin cuci, maka ia memerlukan data-data tentang mesin cuci

untuk mensimulasikan rancangan mesing cuci dengan beban maksimal.

Dalam hal ini, iatidak memerlukan atribut nomor serial mesing cuci.

Sebaliknya, pada saat membuat progaram komputer untuk proses

transaksi pada usaha binatu (laundry) yang mempunyai beberapa mesin

cuci, mungkin diperlukan nomor seri beberapa mesin cuci dan kegiatan ini

tidak memerlukan atribut – atribut sebagaimana yang diperlukan oleh

seorang ahli teknik pembuat mesin cuci.

(42)

2.6.2 Pewar isan

Objek adalah anggota atau instan suatu kelas, dan sebaliknya kelas

adalah sebuah kategori dari beberapa objek yang memunyai atribut dan

operasi yang sama, maka obyek mempunyai semua karakteristik dari

suatu kelas. Atribut yang ditentukan dalam keals dapat diwariskan ke

masing-masing objek dalam kelas tersebut.

Kelas dapat pula mewarisi sifat-sifat kelas lainya. Mesin cuci,

refrigator, microwave oven, radio, televisi dan sebagainya adalah kelas

peralatan lisrik, mereka mewarisi atribut dari kelas Peralatan Listrik.

Misalnnya tipe, dan mewarisi operasi misalnya turn-on dan turn-off.

Dengan kata lain mesin cuci, refigrator, microwave oven, radio dan

televisi merupakan subkelas dari kelas Peralatan Listrik, yang mana

kelas peralatan listrik mewariskan beberapa atribut dan beberapa operasi

ke kelas-kelas tersebut.

Pewarisan tidak berhenti sampai di sini, keals Peralatan Listrik itu

sendiri hanyalah subkelas dari Peralatan. Dimana Kelas Peralatan

mempunyai beberapa subkelas antara lain: Peralatan listrik, Furnitur,

Peralatan dapur dan sebagainya. Dari contoh di atas, maka pewarisan

dapat dibuat bertingkat, Kelas Televisi mewarisi sifat kelas Peralatan

Listrik, dan Kelas Peralatan Listrik mewarisi sifat Kelas Peralatan.

2.6.3 Banyak Bentuk

Kadang - kadang sebuah operasi mempunyai nama yang sama pada

kelas yang berbeda. Misalkan, membuka jendela, membuka pintu,

(43)

membuka surat kabar dan membuka percakapan. Operasi - operasi di atas,

walaupun mempunyai nama yang sama tetapi diberikan pada objek yang

berbeda maka mempunyai makna yang berbeda. Pada masing - masing

persoalan dapat dilakukan operasi yang berbeda - beda walaupun dengan

nama yang sama. Konsep di atas dikenal dengan istilah banyak bentuk

atau polymorphism, yaitu suatu operasi dengan nama yang sama, tetapi

jika diberikan pada objek yang berbeda akan mengakibatkan operasi yang

berbeda.

2.6.4 Pembungkusan

Ketika seseorang menonton televisi, seseorang tersebut tidak

memperdulikan kompleksitas rangkaian elektronika yang ada di dalamnya.

Mereka tidak memperdulikan bagaimana rangkaian elektronika itu

bekerja, mereka hanya memperhatikan tombol - tombol apa saja yang

bisa digunakan untuk mengoperasikannya. Konsep ini dikenal dengan

istilah pembungkusan (encapsulation), yaitu menyembunyikan

kompleksitas dari luat dan hanya membuka operasi-operasi yang

diperlukan saja terhadap objek-objek lain.

2.6.5 Pengir iman Pesan

Bagaimana objek - objek dalam sistem bekerja sama. Mereka

melakukannya dengan mengirimkan pesan dari satu objek ke objek lainya.

Suatu objek mengirimkan pesan ke objek lainya untuk melakukan sebuah

operasi, dan juga dapat menerima pesan dari objek lain untuk

(44)

melakukan operasi lainya.

Sebuah televisi dan remot kontrol adalah sebuah contoh dalam hal

ini. Ketika seseorang ingin menonton acara televisi, seseorang tersebut

mencari remot kontrol, duduk di kursi dan menekan tombol ON. Apa

yang terjadi? Objek remot mengirimkan pesan ke objek Televisi untuk

berubah dirinya sendiri menjadi ON. Objek Televisi menerima pesan ini

dan menjalankan turn-on. Ketika seseorang ingin melihat channel yang

berbeda, seseorang tersebut cukup melakukan klik tombol-tombol di

remote. Objek remot dapat juga berkomunikasi dengan objek Televisi

dalam hal merubah volume suara, memperbaiki gambar, dan sebagainya.

2.6.6 Assosiasi

Pada saat seseorang melakukan turn-on pada sebuah televisi maka

menurut terminologi berorientasi objek, seseorang tersebut sedang

berassosiasi dengan televisi. Kadang - kadang sebuah objek diassosiasikan

dengan objek lainya dengan menggunakan lebih dari satu cara, jika

co-worker Anda adalah juga teman Anda, maka Anda sedang berassosiasi

dengan kelas Mobil dan sekaligus berassosiasi dengan kelas Bis.

2.6.7 Aggregasi

Agregasi atau aggregation adalah bentuk khusus dari assosiasi

yang lebih kuat, dimana assosisasi yang terjadi adalah “part-of” antara

objek yang satu dengan objek yang lainya, atau assosiasi antara

“keseluruhan” dengan “sebagian”. Misalkan, komputer terdiri dari kotak

(45)

CPU, keyboard, mouse, monitor, CD-ROM drive, hardisk, modem

disk drive, printer, dan sebagainya. Di dalam peralatan lainya. Komputer

adalah sebuah aggregasi, komputer dibentuk dari sejumlah komponen

-komponen berbeda sebagai penyusunnya.

Salah satu bentuk aggregasi meliputi hubungan yang kuat antara

satu objek dan objek-objek lainya sebagai komponen pembentuknnya, hal

ini dikenal dengan nama lain yaitu komposisi. Kunci komposisi adalah

bahwa komponen - komponen tersebut ada hanya sebagai penyusun

dari objek gabungan tersebut. Misalkan, objek gabungan kemeja tersusun

dari bagian bodi , lengan, kerah, kancing, lubang kancing, dan kancing

cadangan. Apakah disebut kemeja tanpa kancing?

2.7 Aplikasi Web

Aplikasi web adalah suatu aplikasi yang dapat membentuk

halaman-halaman Web berdasarkan permintaan pemakai. Aplikasi web

juga bisa mencakup permainan interaktif ataupun kelompok diskusi

ataupun kelompok diskusi.

Aplikasi web merupakan salah satu contoh aplikasi klien/server.

Klien mewakili komputer yang digunakan oleh seseorang pemakai yang

hendak menggunakan aplikasi, sedangkan server mewakili komputer yang

menyediakan layanan aplikasi.Dalam konteks ini, klien dan server

berhubungan dengan internet ataupun intranet. Yang menarik, model

klien/server yang menggunakan aplikasi web dapat melibatkan

bermacam-macam platform sebagaimana diperlihatkan pada gambar

(46)

Ga mbar 2.8. Lingkungan client ser ver melibatkan banyak platfor m

Ciri khas yang lain pada penggunaan aplikasi Web, pemakai

menggunakan perangkat lunak yang dinamakan web browser atau sering

disebut browser saja untuk mengakses aplikasi web.Komputer yang

bertindak sebagai server umumnya menyediakan database server, selain

web server yang ditujukan untuk melayani permintaan pemakai yang

hendak mengakses aplikasi web. Database server adalah server

yang melayani akses terhadap database. Oracle dan MySQL merupakan

contoh dari sekian database server. Adapun contoh web server yaitu

Apache (sangat terkenal dilingkungan Linux) dan IIS (InternetInformation

Server), yang merupakan andalan Microsoft.

2.7.1 JavaServerPages(JSP)

Untuk membangkitkan halaman-halaman web sesuai dengan

permintaan pemakai, para pengembang aplikasi web bisa menggunakan

(47)

perangkat lunak seperti JSP, PHP, Perl, dan ASP. JSP (Java Server Pages)

merupakan teknologi yang didasarkan pada Java, yang dapat digunakan

untuk membentuk halaman-halaman web yang bersifat dinamis. Teknologi

ini dikembangkan oleh Sun Microsystems.

Berbeda dengan applet, suatu fitur pada bahasa Java yang

memungkinkan pengembang membuat aplikasi web yang dieksekusi pada

sisi klien, JSP menggunakan pendekatan pemrosesan di sisi server. Pada

model seperti ini, kode sumber JSP dijalankan pada web server. Salah

satu keuntungan model seperti iniadalahmemungkinkan untuk membuat

aplikasi yang independen terhadap sistem Java di sisi Klien.

Dua alasan penting yang membuat JSP banyak digunakan oleh para

pengembang aplikasi web:

1. JSP menggunakan bahasa Java. Bagi para pemrogram yang telah

mengenal Java, sangatlah mudah untuk membuat aplikasi web

dengan JSP mengingat dasar JSP adalah bahasa Java. Dengan

demikian mereka tidak perlu lagi belajar

2. JSP mendukung multiplatform. Dalam hal ini JSP memang bukan

satu-satunya perangkat lunak pembuat aplikasi web yang bersifat

multiplatform. PHP, misalnya, juga bersifat multiplatform.

Keunggulan dari adanya dukungan multiplatform adalah

memungkinkan kode dapat dipindah-pindahkan ke berbagai

platform tanpa perlu melakukan perubahan apapun pada kode

tersebut. Sebagai contoh, Anda bisa menulis kode JSP yang pada

awalnya ditujukan utnuk dijalankan pada Windows, dan kemudian

(48)

dipindahkan ke lingkungan lain, misalnya Linux.

2.7.2 Ar sitektur J SP

Sebelum melangkah lebih jauh tentang bagaimana membuat kode

sumber JSP, ada baiknya bagi Anda untuk mengenali arsitektur JSP,

sehingga Anda mengetahui mekanisme kerja JSP.

Gambar 2.9. Ar sitektur J SP

Pemakai yang ingin mengakses halaman web mula - mula

mengirimkan permintaan halaman web melalui protokol HTTP

(HyperText Transfer Protocol) dalam bentuk JSP (berekstensi.jsp).

Permintaan ini kan disampaikan ke web server. Kemudian web server

mengambil dokumen JSP dan mengirimkan ke JSP Servlet engine. Bagian

inilah yang melakukan pemrosesan kode – kode JSP (termasuk di

dalamnya melakukan pengompilasian) dan membentuk kode HTML.

Berikutnya, kode HTML ini disampaikan oleh web server ke klien yang

memintanya. Kode HTML ini selanjutnya diproses oleh browser

(49)

sehingga pemakai bisa memperoleh informasi dari halaman web yang

dikehendakinya.

Detail pemrosesan oleh JSP Servlet engine adalah sebagai berikut:

1. Melakukan pemilahan (parsing) kode JSP.

2. Membangkitkan kode sumber Servlet.

3. Mengkompilasi kode sumber Servlet menjadi sebuah kelas.

4. Membuat instan servlet.

5. Memberikan keluaran Servlet ke web server.

2.8 Ar sitektur Model View Contr oller (MVC)

Model View Controller (MVC) adalah design pattern atau

arsitektur yang digunakan dalam rekayasa perangkat lunak, di mana terjadi

pemisahan yang jelas antara data (model) dengan user interface (view)

(Nur Widiyanto, 2006). Penerapan MVC tidak hanya terbatas dalam

aplikasi berbasis web. Penggunaan design pattern ini juga terbukti sangat

efektif tetapi dalam semua aplikasi perangkat lunak penggunaann design

pattern ini terbukti sangat efektif.

Dalam aplikasi web, arsitektur yang selama ini digunakan dikenal

dengan nama model 1 dan model 2 (MVC). Model 1 yaitu teknik

pengembangan web yang semua fungsionalitas diserahkan kepada sebuah

objek atau file. Misalnya dalam aplikasi berbasis Java, sebuah

halaman web dikembangkan dengan sebuah file JSP dimana file

tersebut yang menanganin koneksi ke database, melakukan Query untuk

mengambil data, menagani request dan respons, bekerja dengan session,

(50)

serta mengurus tampilan web pun berada dalam file tersebut. Keuntungan

menggunakan Model 1 dalam aplikasi web dapat dikerjakan dengan cepat

ketika aplikasi tersebut tidak terlalu kompleks. Akan tetapi penggunaan

arsitektur Model 1 sudah tidak sesuai lagi ketika aplikasi menjadi lebih

kompleks. Kode program dalam file tersebut akan menjadi sangat

panjang dan rumit dan menyulitkan dalam debuging dan perawatannya.

Terlebih bila aplikasi tersebut sudah termasuk ke dalam kategori

enterprise dan dikerjakan dengan cukup banyak personel dengan

kualifikasi dan spesifikasi berbeda, maka model 1 jelas sudah harus

ditinggalkan (Nur Widiyanto, 2006).

Gambar 2.10. Model 1

Model 2 sering juga disebut dengan arsitektur MVC, yang dalam

implementasinya memisahkan antara bagian bisnis dengan bagian

presentasi. Aplikasi web dibagi menjadi tiga bagian sesuai fungsinya,

yaitu model, view, dan controller. Model berfungsi memodelkan sesuatu

obyek seperti pelanggan, pengguna, barang, transaksi penjualan dan lain

-lain(Nur Widiyanto, 2006). View merupakan bagian yang bertanggung

jawab pada tampilan halaman web. Adapun controller merupakan bagian

(51)

yang bertugas menangani request dari pengguna dan memberikan

response berupa view tertentu. Dalam Java EE, model dapat disusun

dengan JavaBean dan ditopang dengan JDBC atau teknologi ORM,

kemudian view dapat berupa JSP, JSF, Velocity, ataupun Servlet,

sedangkan controller dapat berupa servlet dan turunanya.

Diagram model 2 dapat Anda lihat pada Gambar 2.11. Keuntungan

penggunaan model 2 ini adalah lebih mudah dalam debugging, sesuai

untuk aplikasi yang sederhana sampai ke aplikasi yang kompleks, lebih

mudah dirawat dan dikembangkan, serta sesuai jika dikerjakan oleh

sebuah tim yang terdiri dari banyak personel dengan spesialisasi yang

berbeda. Selain itu, tingkat reusability atau tingkat penggunaan kembali

kode program juga cukup tinggi. Untuk membangun aplikasi Java

enterprise dengan arsitektur MVC, Anda juga tidak perlu terlalu repot

membuatnya dari awal, karena sudah tersedia banyak framework MVC

yang siap pakai dan sudah teruji.

Gambar 2.11 : Model 2

(52)

BAB III

ANALISIS DAN PERANCANGAN SISTEM

Pada bab ini akan dijelaskan mengenai uraian masalah seperti

identifikasi permasalahan dan analisa permasalahan serta perancangan

sistem yang digunakan untuk mendukung pembuatan aplikasi ini. Adapun

perancangan sistem yang dibuat seperti : usecase, activity diagram,

sequence, class diagram

3.1 Identifikasi Masalah

Dari latar belakang masalah diatas maka dapat diidentifikasikan

permasalahan yang terjadi selama ini. Adapun permasalahan tersebut

adalah sebagai berikut :

1. Tidak dicatatnya transaksi pembelian dari suplier membuat pemilik toko

kehilangan data-data supplier.

2. Tidak dicatatnya transaksi penjualan membuat pemilik toko tidak bisa

mengetahui item apa saja yang paling laku dan laporan penjualan perbulan

atau pertahun.

3. Pengelolaan gudang yang masih manual membuat pemilik toko tidak

mengetahui stok barang secara pasti dan sering terjadi kehabisan barang.

Dari identifikasi masalah di atas,dapat diketahui bahwa toko

tersebut sering kehilangan pelanggan dikarenakan tidak mengetahui stok

barang yang sudah habis, tentunya hal ini akan berpengaruh pada

keuntungan yang diperoleh oleh toko tersebut. Selain itu, kurang

(53)

diperhatikanya masalah pencatatan transaksi penjualan dan

pembelian membuat pemilik toko kehilangan informasi - informasi

penting mengenai transaksi perbulan atau pertahun dan informasi -

informasi penting lainya. Oleh karena itu dengan sistem yang akan dibuat

ini, pemilik toko dapat menerapkan dan mengimplementasikan metode

EOQ dan ROP untuk manajemen persediaanya yang bertujuan untuk

menentukan jumlah ekonomis dalam sekali pesan dan menentukan

limit atau batas waktu pemesanan dilihat dari stok barang.

3.2 Per ancangan Sistem

Sub-bab ini akan menjelaskan mengenai proses desain dari aplikasi

jual beli dan manajemen gudang di toko AF yang akan dibuat. Proses

desain sistem aplikasi dalam sub-bab ini dibagi menjadi 4 tahapan :

Pembuatan usecase diagram, activity diagram, sequence diagam, class

diagram.

3.2.1 Usecase Diagram

Pada sistem jual beli dan manajemen gudang melibatkan dua

pengguna, yaitu : administrator dan kasir. Administrator adalah hak akses

paling tinggi dan bisa mengakses semua modul dalam aplikasi ini. Kasir

hanya bisa mengakses modul transaksi penjualan saja. Adapun hasil

rancangan usecase diagram untuk hak akses Administrator :

(54)

Gambar 3.1. Use case diagr am data toko

Administrator dapat mengakses semua menu modul dikarenakan

user ini yang bertanggung jawab penuh terhadap aplikasi, dalam hal ini

adalah pemilik toko. Menu modul yang dapat diakses antara lain :

a) Menu simpan data jenis barang.

1. Menu cari data jenis barang.

b) Extend menu ubah data jenis barang.

1. Menu simpan data suplier.

2. Menu cari data suplier.

(55)

3. Extend menu ubah data suplier.

c) Menu simpan data barang.

d) Menu cari data barang.

1. Extend menu ubah data barang.

2. Extend menu hitung EOQ.

3. Extend menu hitung ROP.

e) Menu lihat data suplier.

1. Extend cetak laporan.

f) Menu lihat data jenis barang.

g) Menu lihat data pembelian.

h) Menu lihat data penjualan.

i) Menu lihat data barang.

Hal pertama yang harus dilakukan adalah mengisi tabel jenis

barang dan suplier terlebih dahulu karena kedua indetifier tabel ini akan

menjadi foreign key di tabel barang. Setelah kedua tabel ini terisi, langkah

selanjutnya adalah mengisi tabel barang. Setelah tabel barang terisi,

menu hitung ROP dan menu hitung EOQ bisa digunakan. Karena kedua

menu ini membutuhkan data barang terlebih dahulu. Usecase diagram

yang kedua adalah usecase transaksi pembelian.

(56)

Gambar 3.2. Use case diagr am tr ansaksi beli

Diagram usecase 3.2 di atas adalah diagram transaksi pembelian

yang hanya bisa dilakukan atau diakses oleh administrator saja.

Administrator harus mencari data barang terlebih dahulu setelah itu

menyimpan data transaksi belinya. Diagram usecase ketiga adalah

transaksi jual yang dapat diakses oleh pengguna administrator dan kasir.

Gambar 3.3 : Usecase diagr am tr ansaksi jual

(57)

Pengguna kasir atau administrator harus mencari data barang

dahulu kemudian menyimpan transaksi penjualannya.

3.2.2 Activity Diagram

Pada sub-bab ini, akan menjelaskan tentang activity diagram dari

masing-masing usecase diagram. Tidak semua usecase dibuat activity

diagramnya, hanya menjelaskan activity diagram simpan data jenis

barang, simpan data suplier, simpan data barang, simpan data transaksi

jual, simpan data transaksi beli, hitung EOQ, hitung ROP, ubah data

jenis barang, ubah data suplier dan ubah data barang.

A. Activity Diagr am Simpan Data Jenis Barang

Diagram ini menjelaskan tentang bagaimana alur kerja pada menu

modul simpan data jenis barang, berikut gambar activity diagram :

Gambar 3.4 : Activity diagr am simpan data jenis bar ang