SISTEM INFORMASI PEMBELIAN, PENJUALAN, DAN INVENTORI BARANG MENGGUNAKAN PENDEKATAN BERORIENTASI OBYEK

(1)

i

PEMBELIAN, PENJUALAN, DAN INVENTORI BARANG

MENGGUNAKAN PENDEKATAN BERORIENTASI OBYEK

STUDI KASUS : TOKO IJO

SKRIPSI

Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Teknik

Jurusan Teknik Informatika

Disusun Oleh : YUNIANTO NIM : 055314020

PROGRAM STUDI TEKNIK INFORM ATIKA

JURUSAN TEKNIK INFORM ATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARM A

YOGYAKARTA

(2)

ii

INFORMATION SYSTEM USING OBJECT ORIENTED

APPROACH

CASE STUDY: TOKO IJO

A THESIS

Presented as a Partial Fulfillment of the Requirements To Obtain Sarjana Teknik Degree

In Informatics Engineering

Disusun Oleh : YUNIANTO NIM : 055314020

INFORMATICS ENGINEERING STUDY PROGRAM

INFORMATICS ENGINEERING DEPARTMENT

FACULTY OF SCIENCE AND TECHNOLOGY

SANATA DHARMA UNIVERSITY

YOGYAKARTA

(3)

(4)

(5)

v

(6)

vi

ABSTRAK

Toko Ijo adalah toko kelontong yang menjual berbagai macam jenis rokok, makanan ringan,dan lain-lain. Permasalahan yang terjadi selama ini adalah penjualan, pembelian dan inventori masih menggunakan kertas untuk menyimpan data-data tersebut dan nota penjualan masih berupa buku nota, sehingga masih kesulitan ketika harus mengecek stok barang, untuk mengetahui harga baru barang jika harga barang tersebut naik/turun dan nota penjualan masih berupa buku nota sehingga penjual harus menulis barang apa yang dibeli dan menghitungnya dengan manual/kalkulator sehingga rentan salah menghitung.

Sistem ini dibuat menggunakan Java yang dikoneksikan dengan basis data berorientasi obyek dan metode pengembangan perangkat lunak berorientasi obyek. Dalam software atau perangkat lunak terdapat 2 user ( pemilik dan

karyawan ). Pemilik menggunakan username dan password untuk mengakses,

pemilik dapat memasukan, mengupdate, menghapus dan mencari data barang ( id

barang, nama barang, stok barang dan harga barang ), serta melakukan transaksi pembelian dan semua yang dilakukan karyawan. Karyawan hanya dapat mencari dan melihat data barang, serta dapat melakukan transaksi penjualan. Dengan terciptanya sistem informasi ini pencarian data barang jauh lebih mudah, transaksi penjualan dan pembelian tidak lagi dilakukan secara manual dan keamanan jauh lebih terjamin.

Perangkat lunak diuji menggunakan metode white box dan black box

(7)

vii

ABSTRACT

Toko Ijo is a small store that sells various kind of goodies such as cigarettes, snacks and so on. There are small problems that occur in regard to keeping track of sold items, items to buy as well as inventory which still use papers to hold all the data and a note book to keep track of sale records. This introduces difficulties when it is time to check on stocked items, or to keep track of item’s new price if the price happens to go up or down. It is also becoming cumbersome when the store owner has to list all of the stocked items and do a manual count that is prone to error.

This system uses Java program that is connected to a database and developed in a object oriented method. The software consists of 2 users (Owner and employee). The owner user requires username and password to access data and this user is privileged to insert, update, delete and search item’s data (item’s id, name, number of stock and item’s price) as well as to perform purchase transaction and everything that employee user can do. Employee user can only search, view item’s data and perform purchase transaction. With this system, data lookups on item can be much easier to do, purchase and sell transactions no longer need to be done manually and the security is much more guaranteed.

(8)

(9)

ix

KATA PENGANTAR

Puji syukur ke hadirat Tuhan Yang Maha Esa atas berkat dan kasihnya sehingga penulis dapat menyelesaikan skripsi ini.

Skripsi ini ditulis untuk memenuhi salah satu syarat dalam memperoleh gelar Sarjana Teknik, Program Studi Teknik Informatika di Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta.

Dalam penulisan skripsi ini penulis menyadari banyak pihak yang telah memberikan sumbangan baik pikiran, waktu, tenaga, bimbingan dan dorongan kepada penulis sehingga akhirnya skripsi ini dapat selesai. Oleh karena itu pada kesempatan ini penulis menyampaikan ucapan terimakasih kepada :

1. Sri Hartati Wijono, S.Si., M.Kom. selaku dosen pembimbing I yang telah memberikan bimbingan, arahan dan petunjuk selama penulisan skripsi. 2. Ridowati Gunawan, S.Kom, M.T. selaku dosen pembimbing II yang telah

memberikan bimbingan, arahan dan petunjuk selama penulisan skripsi. 3. Yosef Agung Cahyanta, S.T., M.T. selaku Dekan Fakultas Sains dan

Teknologi.

4. Puspaningtyas Sanjoyo Adi, S.T., M.T. selaku Kepala Program Studi Teknik Informatika.

5. Eko Hari Parmadi, S.Si., M.Kom dan P.H.Prima Rosa, S.Si, M.Sc selaku dosen penguji yang telah memberikan masukan, saran dan kritik yang membangun untuk skripsi ini.

(10)

x

dan Keponakanku (Steven Rain Martin), Kakak iparku Henny Octavia, Nency Aprilia Alen, Om dan Tante Adi Pranoto, Om Chong, Tante Evi, Tante Hong Liang yang telah banyak memberikan dukungan secara moril maupun materi kepada penulis selama penyusunan skripsi ini.

7. Seluruh dosen pengajar Jurusan Teknik Informatika pada khususnya, staff sekretariat fakultas Teknik, BABPSI, BAA dan AUK pada umumnya. 8. Aquino Ricky Sanjaya,S.T. selaku pemilik Toko Ijo.

9. Teman-temanku angkatan 2005 yang telah memberikan semangat kepada penulis selama penyusunan skripsi ini.

Penulis menyadari bahwa skripsi ini masih banyak kekurangan dan jauh dari kesempurnaan, sehingga segala kritik dan saran yang bersifat membangun sangat penulis harapkan demi perbaikan skripsi ini. Akhirnya dengan segala kekurangan yang ada, penulis berharap agar skripsi ini masih dapat diambil manfaatnya.

Yogyakarta, 19 September 2010

Penulis

(11)

xi

DAFTAR ISI

HALAMAN PERSETUJUAN ... iii

HALAMAN PENGESAHAN ...iv

PERNYATAAN KEASLIAN KARYA ... v

ABSTRACT ... vii

PERNYATAAN PUBLIKASI ... viii

KATA PENGANTAR ……… ix

DAFTAR ISI ...xi

DAFTAR GAMBAR ... xiv

DAFTAR TABEL ... xviii

DAFTAR LAMPIRAN ... xix

BAB I PENDAHULUAN ... 1

1.1 LATAR BELAKANG MASALAH ... 1

1.2 RUMUSAN MASALAH ... 2

1.3 BATASAN MASALAH ... 2

1.4 TUJUAN PENELITIAN DAN MANFAAT PENELITIAN ... 3

1.5 METODE PENELITIAN ... 3

1.6 SISTEMATIKA PENULISAN ... 5

BAB II LANDASAN TEORI ... 7

2.1SISTEM INFORMASI ... 7

2.2TEKNIK DASAR OOAD(OBJECT-ORIENTED ANALYSIS AND DESIGN) ... 7

2.2.1FASTMETODOLOGY ... 8

2.3OODB ... 12

2.4OODBMSPADA DB4O ... 12

2.4.1TIGA JENIS OBYEK QUERY DALAM DB4O ... 13

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 21

3.1PROFILETOKO IJO ... 21

3.2.1GAMBARAN UMUM SISTEM YANG ADA ... 22

3.2.2ANALISIS SISTEM YANG ADA ... 22

3.2.3PROBLEM STATEMENT ... 26

3.3PROBLEM ANALYSIS ... 27

3.3.1CAUSE EFFECTANALYSISANDSYSTEMIMPROVEMENT OBJECTIVE ... 27

3.4REQUIREMENT ANALYSIS ... 30

(12)

xii

3.4.2 USE CASE ... 31

3.4.3USE CASE NARRATIVE ... 32

3.5LOGICAL DESIGN ... 49

3.5.1DIAGRAM AKTIVITAS... 49

3.5.2DIAGRAM KELAS ... 61

3.5.3MATRIKS ASOSIASI ... 66

3.5.4DIAGRAM KELAS ... 68

3.5.3DIAGRAM SEQUENCE ... 73

DESAIN INTERFACE... 82

BAB IV IMPLEMENTASI DAN ANALISA HASIL ... 89

4.1 PENJELASAN ANTAR MUKA SISTEM ... 89

4.1.1ANTAR MUKA MENU LOGIN ... 89

4.1.2ANTAR MUKA MENU UTAMA ... 90

4.1.3ANTAR MUKA MENU BARANG ... 91

4.1.4 ANTAR MUKA MENU TAMBAH BARANG ... 91

4.1.5 ANTAR MUKA MENU UBAH BARANG ... 92

4.1.6 ANTAR MUKA MENU PENJUALAN ... 93

4.1.7ANTAR MUKA MENU PEMBELIAN ... 94

4.1.8ANTAR MUKA MENU DISTRIBUTOR ... 95

4.1.9ANTAR MUKA MENU TAMBAH DATA DISTRIBUTOR ... 96

4.1.10ANTAR MUKA MENU UBAH DATA DISTRIBUTOR ... 97

4.1.11ANTAR MUKA MENU DATA KARYAWAN ... 97

4.1.12ANTAR MUKA MENU TAMBAH DATA KARYAWAN ... 98

4.1.13ANTAR MUKA MENU RETUR PENJUALAN ... 99

4.1.14 ANTAR MUKA MENU RETUR PEMBELIAN ... 100

4.1.15 ANTAR MUKA MENU LAPORAN PENJUALAN ... 101

4.1.16 ANTAR MUKA MENU LAPORAN PEMBELIAN ... 102

4.1.17ANTAR MUKA MENU LAPORAN DETAIL PENJUALAN ... 102

4.1.18ANTAR MUKA MENU LAPORAN DETAIL PEMBELIAN TUNAI ... 103

4.1.19ANTAR MUKA MENU LAPORAN DETAIL PEMBELIAN KREDIT ... 104

4.1.20ANTAR MUKA MENU PEMBAYARAN... 104

4.1.21ANTAR MUKA MENU BAYAR HUTANG ... 105

4.1.22ANTAR MUKA MENU PENCARIAN BARANG ... 106

4.1.23ANTAR MUKA MENU PENCARIAN DATA DISTRIBUTOR ... 106

4.1.24 ANTAR MUKA MENU HAK AKSES ... 107

4.1.25ANTAR MUKA MENU UBAH PASSWORDADMIN ... 107

4.1.26ANTAR MUKA MENU UBAHPASSWORD KARYAWAN ... 108

4.1.27ANTAR MUKA MENU UBAH DATA KARYAWAN ... 108

(13)

xiii

4.3 PENJELASAN KONSEP MVCMENGGUNAKAN JAVA ... 113

4.3.2 CONTROLLER ... 115

4.3.2.1 CONTROLLER PENJUALAN ... 115

4.3.2.2 CONTROLLER LAPORAN PEMBELIAN ... 119

4.3.2MODEL ... 123

BAB V PENGUJIAN SISTEM ... 127

5.1 PENGUJIAN WHITE BOX ... 127

5.1.1 PENGUJIAN PROSES LOGIN ... 127

5.1.2 PENGUJIAN PROSES PENGUBAHAN PASSWORD ... 128

5.1.3 PENGUJIAN PROSES MENU UTAMA ... 128

5.1.4 PENGUJIAN PROSES TAMBAH BARANG ... 128

5.1.5 PENGUJIAN PROSES UBAH DATA BARANG ... 129

5.1.6 PENGUJIAN PROSES TAMBAH DATA DISTRIBUTOR ... 129

5.1.7 PENGUJIAN PROSES UBAH DATA DISTRIBUTOR. ... 130

5.1.8PENGUJIAN PROSES SEARCHINGDATA DISTRIBUTOR ... 130

5.1.9 PENGUJIAN PROSES TAMBAH DATA KARYAWAN ... 130

5.1.10 PROSES PENGUJIAN UBAH DATA KARYAWAN ... 130

5.1.11 PROSES PENGUJIAN UBAH DATA PASSWORD KARYAWAN ... 130

5.1.12 PROSES PENGUJIAN LAPORAN ... 131

5.1.13PROSES PENGUJIAN PENCARIAN DATA BARANG ... 131

5.1.14 PROSES PENGUJIAN DATA TRANSAKSI ... 131

5.1.15 PROSES PENGUJIAN RETUR ... 131

5.1.16 PROSES PENGUJIAN BAYAR HUTANG ... 132

5.1.17 PROSES PENGUJIAN PEMBELIAN ... 132

5.1.18 PROSES PENGUJIAN PENJUALAN ... 132

5.2 PENGUJIAN BLACK BOX ... 133

BAB VI KESIMPULAN DAN SARAN ... 171

(14)

xiv

DAFTAR GAMBAR

GAMBAR 2.1 ENTITY CLASS BARANG ... 15

GAMBAR 3.1 KONTEKS DIAGRAM ... 30

GAMBAR 3.3 USE CASE KARYAWAN ... 32

GAMBAR 3.4 DIAGRAM AKTIVITAS MENCATAT DATA PENJUALAN(A). ... 49

GAMBAR 3.5 DIAGRAM AKTIVITAS MENCATAT DATA PENJUALAN(B)... 50

GAMBAR 3.6 DIAGRAM AKTIVITAS MENCATAT DATA RETUR PENJUALAN. . 51

GAMBAR 3.7 DIAGRAM AKTIVITAS MENGHAPUS DATA PENJUALAN. ... 52

GAMBAR 3.8 DIAGRAM AKTIVITAS PENCARIAN DATA BARANG. ... 52

GAMBAR 3.9 DIAGRAM AKTIVITAS PEMESANAN BARANG. ... 53

GAMBAR 3.10 DIAGRAM AKTIVITAS MENCATAT DATA RETUR BARANG. ... 54

GAMBAR 3.11 DIAGRAM AKTIVITAS PENCARIAN DATA PEMBELIAN. ... 54

GAMBAR 3.12 DIAGRAM AKTIVITAS PENCATATAN DATA PEMBELIAN. ... 55

GAMBAR 3.13 DIAGRAM AKTIVITAS PENCATATAN DATA DISTRIBUTOR. ... 55

GAMBAR 3.14 DIAGRAM AKTIVITAS MENGUBAH DATA DISTRIBUTOR. ... 56

GAMBAR 3.15 DIAGRAM AKTIVITAS MENCARI DATA DISTRIBUTOR. ... 56

GAMBAR 3.16 DIAGRAM AKTIVITAS MEMBUAT DATA KARYAWAN BARU. . 57

GAMBAR 3.17 DIAGRAM AKTIVITAS MENGUBAH DATA KARYAWAN. ... 57

GAMBAR 3.18 DIAGRAM AKTIVITAS MENGECEK INVENTORI. ... 58

GAMBAR 3.19 DIAGRAM AKTIVITAS MENCATAT DATA INVENTORI BARU. . 58

GAMBAR 3.20 DIAGRAM AKTIVITAS MENGUBAH DATA INVENTORI. ... 59

GAMBAR 3.21 DIAGRAM AKTIVITAS PENENTUAN HARGA JUAL. ... 59

GAMBAR 3.22 DIAGRAM AKTIVITAS MENGUBAH PASSWORD ADMIN. ... 60

GAMBAR 3.23 DIAGRAM AKTIVITAS MENGHAPUS DATA KARYAWAN. ... 60

GAMBAR 3.24 MATRIKS ASOSIASI (A) ... 66

GAMBAR 3.25 MATRIKS ASOSIASI (B) ... 67

GAMBAR 3.26 DIAGRAM KELAS ... 68

GAMBAR 3.27 IMPLEMENTASI MENU OPERATOR... 69

(15)

xv

GAMBAR 3.29 IMPLEMENTASI MENU KARYAWAN. ... 70

GAMBAR 3.30 IMPLEMENTASI MENU DISTRIBUTOR. ... 70

GAMBAR 3.31 IMPLEMENTASI MENU PENJUALAN. ... 71

GAMBAR 3.32 IMPLEMENTASI MENU PEMBELIAN. ... 71

GAMBAR 3.33 IMPLEMENTASI MENU RETUR BELI ... 72

GAMBAR 3.34 IMPLEMENTASI MENU RETUR JUAL. ... 72

GAMBAR 3.35 DIAGRAM SEQUENCE PENCARIAN DATA BARANG. ... 73

GAMBAR 3.37 DIAGRAM SEQUENCE PENGINPUTAN DATA INVENTORI BARANG BARU. ... 74

GAMBAR 3.38 DIAGRAM SEQUENCE PENGUBAHAN DATA INVENTORI BARANG. ... 74

GAMBAR 3.39 DIAGRAM SEQUENCE PENJUALAN BARANG. ... 75

GAMBAR 3.40 DIAGRAM SEQUENCE RETUR PENJUALAN BARANG. ... 75

GAMBAR 3.41 DIAGRAM SEQUENCE PEMESANAN/PEMBELIAN BARANG. ... 75

GAMBAR 3.42 DIAGRAM SEQUENCE DISTRIBUTOR BARU. ... 76

GAMBAR 3.43 DIAGRAM SEQUENCE UBAH DATA DISTRIBUTOR. ... 76

GAMBAR 3.44 DIAGRAM SEQUENCE PENCARIAN DATA DISTRIBUTOR. ... 77

GAMBAR 3.45 DIAGRAM SEQUENCE INPUTAN DATA KARYAWAN BARU. ... 77

GAMBAR 3.46 DIAGRAM SEQUENCE PENGUBAHAN DATA KARYAWAN. ... 78

GAMBAR 3.47 DIAGRAM SEQUENCE PENCARIAN DATA KARYAWAN. ... 78

GAMBAR 3.48 DIAGRAM SEQUENCE PENCATATAN DATA RETUR PEMBELIAN. ... 79

GAMBAR 3.49 DIAGRAM SEQUENCE PENCARIAN DATA PEMBELIAN. ... 79

GAMBAR 3.50 DIAGRAM SEQUENCE VIEW DATA HUTANG ... 80

GAMBAR 3.51 DIAGRAM SEQUENCE PEMBAYARAN HUTANG ... 80

GAMBAR 3.52 DIAGRAM SEQUENCE PENCARIAN DATA PENJUALAN. ... 81

GAMBAR 3.53 DIAGRAM SEQUENCE PENGUBAHAN PASSWORD ADMIN. ... 81

GAMBAR 3.54 DIAGRAM SEQUENCE PENGHAPUSAN DATA KARYAWAN. ... 81

GAMBAR 3.55 FORM LOGIN.... 82

(16)

xvi

GAMBAR 3.57 FORM BARANG. ... 83

GAMBAR 3.58 FORM TAMBAH BARANG. ... 83

GAMBAR 3.59 FORM UBAH BARANG. ... 84

GAMBAR 3.60 FORM PENJUALAN. ... 84

GAMBAR 3.61 FORM PEMBELIAN. ... 85

GAMBAR 3.63 FORM TAMBAH KARYAWAN. ... 85

GAMBAR 3.64 FORM UBAH KARYAWAN. ... 86

GAMBAR 3.65 FORM PENGUBAHAN PASSWORD. ... 86

GAMBAR 3.66 FORM LAPORAN KEUANGAN. ... 86

GAMBAR 3.67 FORM DATA TRANSAKSI. ... 87

GAMBAR 3.68 FORM RETUR BARANG. ... 87

GAMBAR 3.69 FORM DISTRIBUTOR. ... 87

GAMBAR 3.70 FORM TAMBAH DATA DISTRIBUTOR. ... 88

GAMBAR 3.71 FORM UBAH DATA DISTRIBUTOR. ... 88

GAMBAR 3.72 FORM PENCARIAN DATA BARANG DAN DISTRIBUTOR. ... 88

GAMBAR 4.1 MENU LOGIN ... 89

GAMBAR 4.2 MENU UTAMA. ... 90

GAMBAR 4.3 MENU BARANG ... 91

GAMBAR 4.4 MENU TAMBAH BARANG... 91

GAMBAR 4.5 MENU MENGUBAH DATA BARANG. ... 92

GAMBAR 4.6 MENU PENJUALAN. ... 93

GAMBAR 4.7 MENU PEMBELIAN ... 94

GAMBAR 4.8 MENU DISTRIBUTOR ... 95

GAMBAR 4.10 MENU UBAH DATA DISTRIBUTOR. ... 97

GAMBAR 4.12 MENU TAMBAH DATA KARYAWAN ... 98

GAMBAR 4.13 MENU RETUR PENJUALAN ... 99

GAMBAR 4.14 MENU RETUR PEMBELIAN ... 100

GAMBAR 4.17 MENU LAPORAN PENJUALAN ... 101

(17)

xvii

GAMBAR 4.17 MENU LAPORAN DETAIL PENJUALAN ... 102

GAMBAR 4.18 MENU LAPORAN DETAIL PEMBELIAN TUNAI ... 103

GAMBAR 4.21 MENU BAYAR HUTANG ... 105

GAMBAR 4.22 MENU PENCARIAN BARANG ... 106

GAMBAR 4.23 MENU PENCARIAN DISTRIBUTOR ... 106

GAMBAR 4.25 MENU UBAH PASSWORD ADMIN. ... 107

(18)

xviii

DAFTAR TABEL

TABEL 5.2.1 HASIL PENGUJIAN BLACK BOX PROSES LOGIN ... 133

TABEL 5.2.2 HASIL PENGUJIAN BLACK BOX PROSES PENGUBAHAN PASSWORD ... 134

TABEL 5.2.3 HASIL PENGUJIAN BLACK BOX MENU UTAMA ... 135

TABEL 5.2.4 HASIL PENGUJIAN BLACK BOX MENU HAK AKSES. ... 139

TABEL 5.2.5 HASIL PENGUJIAN BLACK BOX MENU BARANG. ... 142

TABEL 5.2.6 HASIL PENGUJIAN BLACK BOX MENU TAMBAH BARANG. ... 143

TABEL 5.2.7 HASIL PENGUJIAN BLACK BOX MENU UBAH BARANG. ... 145

TABEL 5.2.7 HASIL PENGUJIAN BLACK BOX MENU DISTRIBUTOR. ... 147

TABEL 5.2.7 HASIL PENGUJIAN BLACK BOX MENU TAMBAH DISTRIBUTOR. 149 TABEL 5.2.8 HASIL PENGUJIAN BLACK BOX MENU UBAH DISTRIBUTOR. ... 150

TABEL 5.2.9 HASIL PENGUJIAN BLACK BOX MENU SEARCHING DISTRIBUTOR. ... 152

TABEL 5.2.10 HASIL PENGUJIAN BLACK BOX MENU KARYAWAN. ... 153

TABEL 5.2.11 HASIL PENGUJIAN BLACK BOX MENU TAMBAH KARYAWAN. . 154

TABEL 5.2.12 HASIL PENGUJIAN BLACK BOX MENU UBAH KARYAWAN. ... 156

TABEL 5.2.13 HASIL PENGUJIAN BLACK BOX MENU UBAH PASSWORD KARYAWAN. ... 157

TABEL 5.2.14 HASIL PENGUJIAN BLACK BOX MENU LAPORAN. ... 159

TABEL 5.2.15 HASIL PENGUJIAN BLACK BOX MENU PENCARIAN BARANG. .. 160

TABEL 5.2.16 HASIL PENGUJIAN BLACK BOX MENU DATA TRANSAKSI. ... 162

TABEL 5.2.17 HASIL PENGUJIAN BLACK BOX PROSES RETUR. ... 163

TABEL 5.2.18 HASIL PENGUJIAN BLACK BOX PROSES BAYAR HUTANG. ... 165

TABEL 5.2.19 HASIL PENGUJIAN BLACK BOX PROSES PEMBAYARAN. ... 166

TABEL 5.2.20 HASIL PENGUJIAN BLACK BOX PROSES PEMBELIAN... 166

(19)

xix

DAFTAR LAMPIRAN

(20)

1

BAB I

PENDAHULUAN

1.1

Latar Belakang Masalah

Toko Ijo adalah toko kelontong yang menjual berbagai macam jenis rokok, makanan ringan, dan berbagai keperluan sehari-hari. Semakin banyak pelanggan Toko Ijo, maka Toko Ijo semakin banyak menyediakan barang kebutuhan pelanggan. Dampak yang terjadi adalah item barang bertambah banyak. Awalnya pemilik toko dan karyawan hapal dengan item barang yang ada di Toko Ijo. Perkembangan Toko Ijo yang semakin pesat, menyebabkan pemilik dan karyawan kesulitan mengingat item barang yang ada di Toko Ijo, terutama mengenai harga barang yang sering mengalami perubahan. Tentunya permasalahan ini akan mengurangi pelayanan kepada konsumen.

(21)

Untuk menjamin kepuasan pembeli, pemilik toko mempunyai inisiatif membangun sebuah sistem informasi dengan tujuan mengatasi masalah-masalah tersebut. Sistem informasi yang akan dibangun menggunakan metodologi pengembangan perangkat lunak berorientasi obyek. DBMS yang digunakan adalah open source db4o(www.db4o.com).

Bahasa pemrograman yang digunakan untuk mengembangkan sistem informasi Toko Ijo adalah Java.

1.2

Rumusan Masalah

Bagaimana membuat sistem informasi pembelian, penjualan, dan inventori barang dengan pendekatan berorientasi obyek yang dapat:

1. Menangani proses pembelian. 2. Menangani proses penjualan. 3. Mengelola inventori.

1.3

Batasan Masalah

1. Sistem tidak menghitung laba-rugi.

2. Sistem ini tidak menangani sistem informasi akuntansinya. 3. Sistem ini tidak menangani penjualan secara kredit.

(22)

1.4

Tujuan Penelitian dan Manfaat Penelitian

1.4.1. Tujuan Penelitian

- Menerapkan metodologi pengembangan perangkat lunak berorientasi obyek pada sistem informasi Toko Ijo menggunakan bahasa pemrograman Java dan DBMS berorientasi obyek dengan db4o.

- Membuat sistem informasi yang dapat menangani proses pembelian, penjualan dan dapat mengelola inventori.

1.4.2 Manfaat Penelitian

Sistem informasi ini dibuat untuk membantu mengatasi masalah-masalah yang terjadi pada Toko Ijo. Sistem yang lama masih menggunakan buku dan nota dalam melakukan proses transaksi. Proses transaksi ditulis dengan tangan sehingga rentan sekali dengan kesalahan-kesalahan yang dapat menyebabkan kerugian, baik dipihak Toko Ijo ataupun dipihak pembeli.

1.5 Metode Penelitian

Metode penelitian yang digunakan adalah studi kasus. Adapun metode pengembangan sistem yang digunakan adalah metodologi FAST(Whitten. 2004). Langkah – langkah yang dilakukan adalah sebagai

(23)

I. Scope definition

Fase ini merupakan tahap pertama dalam melakukan pengembangan suatu sistem. Dalam fase ini dilakukan penentuan batasan-batasan sistem, serta penyusunan project plan.

II. Problem analysis

Dalam fase ini system analyst melakukan analisis menyeluruh

terhadap permasalahan dari sistem yang akan dikembangkan. Dengan melakukan analisa, system analyst bisa memiliki pengertian menyeluruh

terhadap permasalahan sistem, penyebab permasalahan tersebut, serta menentukan apakah permasalahan tersebut dapat diselesaikan.

III. Requirement analysis

Dalam fase ini system analyst melakukan analisa terhadap business requirement dari sistem, sesuai dengan requirement yang dibutuhkan dan

diinginkan user yang menggunakan sistem tersebut.

IV. Logical design

Dalam fase ini business requirement yang ada diterjemahkan

dalam bentuk diagram yang disebut system model.

V. Decision analysis

Permasalahan yang dihadapi sistem biasanya dapat diselesaikan dengan berbagai solusi. Dalam fase ini, system analyst bertugas untuk

(24)

VI. Physical design and integration

Physical design berfokus pada view yang berbasis teknologi dari

sistem yang meliputi : physical database design specification, physical business process dan software design specification, dan physical user and system interface specification.

VII. Construction and testing

Fase ini mempunyai dua tujuan yaitu membangun dan menguji sistem apakah sudah sesuai dengan kebutuhan dan spesifikasi dari desain fisik. Dan kedua mengimplementasikan interface antara sistem yang baru

dengan sistem yang ada.

VIII. Instalation and delivery

Kegiatan yang ada pada fase ini: instalasi sistem, kuisioner, final testing. Juga menyiapkan prosedur konversi. Outputnya adalah petunjuk

penggunaan.

1.6

Sistematika Penulisan

Sistematika penulisan skripsi ini adalah sebagai berikut :

BAB I PENDAHULUAN

(25)

masalah, tujuan penulisan, metode penelitian, serta sistematika penulisan.

BAB II LANDASAN TEORI

Bab ini mengemukakan teori – teori yang mendukung mengenai teknologi yang mendasari pembuatan aplikasi ini, yaitu OOAD, OODB, dan db4o.

BAB III ANALISIS dan PERANCANGAN SISTEM

Bab ini membahas analisa kebutuhan dan perancangan sistem, mencakup rancangan basis data dan rancangan antar muka yang akan digunakan.

BAB IV IMPLEMENTASI dan HASIL SISTEM

Bab ini membahas implementasi dalam bentuk program berdasarkan analisa dan perancangan yang telah dilakukan.

BAB V PENGUJIAN SISTEM

Bab ini berisi pengujian dengan black box dan white box untuk

menguji sistem informasi penjualan, pembelian, dan inventori dengan melakukan pendekatan berbasis obyek.

BAB VI PENUTUP

(26)

7

BAB II

LANDASAN TEORI

2.1 Sistem Informasi

Sistem informasi adalah suatu sistem di dalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi harian, bersifat manajerial dan kegiatan strategi dari suatu organisasi dan menyediakan pihak luar tertentu dengan laporan-laporan yang diperlukan (Leitch. 1983).

Untuk metodologi pengembangan database terdiri dari banyaka model,

diantaranya adalah model relasional database, model hierarkis, model

jaringan, obyek oriented database, obyek relasional database, dan lain

sebagainya.

2.2 Teknik Dasar OOAD (

Object-Oriented Analysis and Design

)

Macam-macam metodologi OOAD:

 Architected Rapid Application Development (Architected RAD).

 Dynamic Systems Development Methodology (DSDM).

 Joint Application Development (JAD).

 Information Engineering (IE).

(27)

 Rational Unified Process (RUP).

 Structured Analysis and Design.

 eXtreme Programming (XP).

 Fast Mehtodology.

2.2.1 FAST Metodology

Metode pengembangan sistem yang digunakan adalah metodologi FAST(Whitten. 2004). Langkah – langkah yang dilakukan adalah sebagai

berikut :

I. Scope definition

Fase ini merupakan tahap pertama dalam melakukan pengembangan suatu sistem. Dalam fase ini dilakukan penentuan batasan-batasan sistem, serta penyusunan project plan.

II. Problem analysis

Dalam fase ini system analyst melakukan analisis menyeluruh

terhadap permasalahan dari sistem yang akan dikembangkan. Dengan melakukan analisa, system analyst bisa memiliki pengertian menyeluruh

(28)

III. Requirement analysis

Dalam fase ini system analyst melakukan analisa terhadap business requirement dari sistem, sesuai dengan requirement yang dibutuhkan dan

diinginkan user yang menggunakan sistem tersebut.

IV. Logical design

Dalam fase ini business requirement yang ada diterjemahkan

dalam bentuk gambar-gambar yang disebut system model.

V. Decision analysis

Permasalahan yang dihadapi sistem biasanya dapat diselesaikan dengan berbagai solusi. Dalam fase ini, system analyst bertugas untuk

mencari dan menentukan solusi terbaik yang dapat digunakan untuk menyelesaikan permasalahan yang dihadapi sistem.

VI. Physical design and integration

Physical design berfokus pada view yang berbasis teknologi dari

sistem yang meliputi : Physical database design specification, Physical business process dan Software design specification, dan Physical user and System interface specification.

VII. Construction and testing

(29)

design. Dan kedua mengimplementasikan interface antara sistem yang

baru dengan sistem yang ada.

VIII. Instalation and delivery

Kegiatan yang ada pada fase ini: instalasi sistem, kuisioner, final testing. Juga menyiapkan prosedur konversi. Outputnya adalah petunjuk

penggunaan.

Dalam dunia pemodelan, metodologi implementasi obyek walaupun terikat kaidah-kaidah standar, namun teknik pemilihan obyek tidak terlepas pada subyektifitas analyst & designer. Beberapa obyek akan

diabaikan dan beberapa obyek menjadi perhatian untuk diimplementasikan di dalam sistem. Hal ini sah-sah saja karena kenyataan bahwa suatu permasalahan sudah tentu memiliki lebih dari satu solusi. Ada 3 (tiga) teknik/konsep dasar dalam konsep berorientasi obyek, yaitu pemodulan (encapsulation), penurunan (inheritance) dan polymorphism.

a. Pemodulan (Encapsulation)

Enkapsulasi memisahkan antara bagian publik (yang bisa dilihat oleh pihak luar (obyek lain) dan bagian privat (internal object itu sendiri)

dengan tegas  fitur ini memberi keleluasaan/independensi untuk bekerja dengan aspek internal tanpa harus bergantung pada aspek publik/eksternal

(30)

dengan menekan tombol. Tanpa harus tahu bagaimana proses itu sebenarnya terjadi. Disini terdapat penyembunyian informasi milik rice cooker, sehingga tidak perlu diketahui seorang ibu. Dengan demikian

menanak nasi oleh ibu menjadi sesuatu yang menjadi dasar bagi konsep

information hiding.

b. Penurunan (Inheritance)

Inheritance adalah obyek-obyek memiliki banyak persamaan, namun ada

sedikit perbedaan. Contoh dengan beberapa buah mobil yang mempunyai kegunaan yang berbeda-beda. Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan dan minibus. Walaupun demikian obyek-obyek ini memiliki kesamaan yaitu teridentifikasi sebagai obyek mobil, obyek ini dapat dikatakan sebagai obyek induk (parent). Sedangkan minibus

dikatakan sebagai obyek anak (child), hal ini juga berarti semua operasi

yang berlaku pada mobil berlaku juga pada minibus. c. Polymorphism

Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek mobil yang sama, namun memiliki juga perbedaan. Misalnya suara truk lebih keras dari pada minibus, hal ini juga berlaku pada obyek anak (child)

melakukan metoda yang sama dengan algoritma berbeda dari obyek induknya. Hal ini yang disebut polymorphism, teknik atau konsep dasar

(31)

2.3 OODB

Object Oriented Database adalah sebuah sistem database yang

menggabungkan semua konsep penting dari object oriented (Whitten. 2004).

Tujuan OODBMS dikembangkan pada awal 1990 untuk menyediakan penyimpanan obyek yang persistence. Produk-produk ini belum sukses

secara komersil, karena memerlukan konversi data yang ada menjadi format OODBMS. Organisasi-organisasi terpaksa melakukan konversi walaupun mahal. OOP membutuhkan penyimpanan obyek yang persistence. Sehingga

beberapa DBMS tradisional menambah kemampuan produknya agar mampu menyimpan obyek sebaik penyimpanan data yang relasional. Produk ini disebut Object-Relational DBMS, misalnya Oracle yang telah

mengembangkan fasilitas-fasilitas untuk pemodelan dan penyimpanan obyek. Sebuah DBMS harus mendukung untuk penyimpanan obyek yang persisten, yaitu obyek yang survive setelah adanya usersession atau program

aplikasi yang dibuat setelah terjadi terminated. Ini merupakan hal yang

kontras untuk obyek transient yang berakhir saat melakukan invocation dari

program. Persisten objek harus tetap ada sampai tidak ada lagi yang membutuhkan, pada titik ini maka obyek akan di-delete.

2.4 OODBMS Pada DB4O

(32)

2.4.1 Tiga Jenis Obyek Query dalam db4o

Di dalam OODBMS db4o, terdapat tiga jenis query yang dipakai untuk melakukan proses retrieving obyek dari database.

Ketiga jenis obyek query itu adalah : Query by example ( atau sering

disingkat QBE), SODA obyek query API, dan Native obyek query.

Ketiga obyek query ini masing-masing dibahas sebagai berikut:

1. Queryby Example (QBE)

QBE adalah suatu bentuk query yang disediakan oleh db4o

yang ditunjukan untuk para pemula yang baru melakukan penyesuaian dengan Db4o. Dengan QBE diharapkan para user yang masih berstatus sebagai pemula dapat memulai start dengan cepat untuk menyimpan atau mendapatkan kembali obyek dari

database.

Ketika menggunakan QBE, kita akan membuat suatu

prototype obyek, kemudian kita akan meminta db4o untuk

mengembalikan obyek dari database yang kriterianya bersesuaian dengan field dari prototype obyek yang kita berikan. Berikut

potongan kode program yang mendemonstrasikan QBE:

try

{

Barang item = new Barang(null, 0);

objectSet hasil = Db.get(item);

(33)

finally

{

Db.close();

}

QBE biasanya dipakai oleh para pemula yang baru belajar db4o agar dapat memulai dengan cepat. Namun secara umum db4o tidak bermaksud membuat QBE untuk dipakai sebagai query

untuk membuat aplikasi software sungguhan. Hal ini disebabkan

oleh karena QBE tidak dirancang untuk melakukan advance query. Untuk melakukan advance query dalam db4o kita harus

menggunakan native object query atau SODA object query API.

2. SODA Obyek Query API

SODA query API merupakan low level query API di dalam

db4o yang membolehkan kita melakukan akses secara langsung ke dalam kumpulan obyek. Menurut db4o Corp, proses query

yang dilakukan dengan menggunakan SODA relatif lebih cepat karena query dilakukan pada tingkat API. Namun demikian,

penulisan obyek query dengan pendekatan SODA dirasakan jauh

lebih bertele-tele karena memanggil fungsi API. SODA query API

sangat berguna untuk mengonstruksi dynamic query pada saat runtime.

(34)

string tersebut dijadikan sebagai parameter ketika terjadi

pemanggilan fungsi API. Oleh karenanya SODA tidak sempurna saat dilakukan typesafe. Contohnya :

Gambar 2.1 Entity Class Barang 2.1Simple Obyek Query dalam SODA API

Semua bentuk query dalam db4o, baik yang simpel maupun

yang kompleks semuanya diciptakan melalui method query()

dari class ObjectContainer. Adapun segala constraint dari query tersebut dapat kita tambahkan melalui method tersebut.

Dalam db4o, tingkat kompleksitas suatu query ditentukan dari

banyak atau sedikitnya constraint. Semakin banyak constraint-nya, maka obyek query-nya semakin kompleks.

Sebaliknya semakin sedikit constraint-nya, maka obyek query-nya semakin simpel. Contoh:

package simplequery1;

import java.io.*;

import com.db4o.*;

import com.db4o.query.*;

(35)

public class Main {

/** Creates a new instance of Main */

public Main()

{

ObjectContainer Db =

Db4o.openFile("Barang3.ODB");

Query ObjectQuery = Db.query();

ObjectQuery.constrain(Barang.class);

ObjectSet Result = ObjectQuery.execute();

ListResult(Result);

Db.close();

}

public static void ListResult(ObjectSet Hasil)

{

System.out.println("Result:

"+Hasil.size());

while (Hasil.hasNext())

{

System.out.println(Hasil.next());

}

/**

* @param args the command line arguments

*/

(36)

{

// TODO code application logic here

Main Q1 = new Main();

}

Untuk membuat obyek query dalam SODA API,

pertama-tama import package com.db4o.query.*. Selanjutnya kita

meng-create SODA query yang baru. Kemudian melalui interface ObjectQuery kita menambahkan constraint yang

diperlukan. Dalam query ini constraint-nya adalah

Barang.class, yang artinya kita meminta API melakukan

proses retrieving obyek-obyek yang berasal dari classifier

Barang. Selanjutnya ObjectQuery dieksekusi dan hasil query

-nya dimasukkan ke dalam ObjectSet collection. Kemudian

obyek-obyek dalam collection di-retrieve dan ditampilkan di

layar. 3. Native Query

Native query adalah obyek query yang utama di dalam

db4o. Saat ini semua platform db4o, baik untuk Java atau dotNet mendukung native query. Penggunaan native query memberikan

(37)

 Query 100% native, karenanya dapat meningkatkan

produktivitas. Programmer dapat membuat query tanpa harus

memikirkan querylanguage dan API.

 Query 100% type-safe, sehingga mendukung proses type checking, syntaxchecking dan refactoring.

 Query 100% object-oriented. Query harus dapat dijalankan

pada bahasa itu sendiri. Pelanggaran terhadap norma-norma

object-oriented pun dapat dieliminasi.

 Query dapat di-prototype, di-test, dan dijalankan pada collection di memori tanpa database backend.

 Optimization. Merupakan komponen baru yang menjadi kunci

dari native query. Kita membuat ekspresi native query dan

database harus dapat mengeksekusinya pada tingkat performa yang sama dengan string base query yang telah kita bahas

sebelumnya. Contoh :

import java.io.*;

import com.db4o.*;

import com.db4o.query.*;

import PDM.Barang;

public class Main{

/** Creates a new instance of Main */

(38)

ObjectContainer Db =

Db4o.openFile("Barang3.ODB");//untuk membuat database

barang3.odb

ObjectSet Barangku = Db.query(new Predicate() //query

menampilkan data dalam database dengan sebuah kondisi

{

public boolean match(Barang barang)

{

return barang.GetHarga() > 300000.0 &&

barang.GetPabrikasi() == "Olympic";

}

});

ListResult(Barangku);//untuk menampung

data hasil query

Db.close();//menutup koneksi

}

public static void ListResult(ObjectSet Hasil)

{

System.out.println("Result:

"+Hasil.size());

while (Hasil.hasNext())

{

System.out.println(Hasil.next());

}

public static void main(String[] args)

{

(39)

Main Noq1 = new Main();

}

(40)

21

BAB III

ANALISIS DAN PERANCANGAN SISTEM

Metodologi FAST terdiri atas beberapa tahapan, yaitu:

I. Scope Definition.

II. Problem Analysis.

III. Requirements Analysis.

IV. Logical Design.

V. Decision Analysis.

VI. Physical Design and Integration.

VII. Construction and Testing.

VIII. Installation and Delivery.

3.1

Profile

Toko Ijo

(41)

3.2 Scope Definition/ Mendefinisikan Ruang Lingkup

3.2.1 Gambaran Umum Sistem Yang Ada

Ketika konsumen ingin membeli barang di Toko Ijo, pelayan atau pemilik toko akan menanyakan barang apa yang ingin dibeli. Kemudian pelayan atau pemilik akan mengambilkan barang yang diminta oleh konsumen sekaligus memberitahukan harganya. Jika harga sesuai konsumen tinggal membayarnya.

Untuk penyediaan barang-barang yang ada di Toko Ijo terdiri dari beberapa cara, yaitu dengan cara memesan terlebih dahulu kepada sales / agen kemudian barang dikirim kira-kira 2-3 hari kemudian, agen/sales langsung datang dengan membawa barang dan menanyakan barang yang dibutuhkan mau ditambah atau tidak, dan ada orang yang menitipkan barang kepada Toko Ijo.

3.2.2 Analisis Sistem yang Ada

Problem-solving framework PIECES digunakan untuk

mendefinisikan problems, opportunities dan directives yang ada.

Setiap huruf dalam PIECES merepresentasikan sebuah kategori dalam perumusan masalah yang ada.

(42)

Performance.

 Bukti/nota transaksi penjualan dan pembelian masih ditulis dengan tangan (manual), sehingga jika nota/bukti hilang tidak terdapat backup.

 Daftar harga ditulis dengan tangan (di barangnya langsung dan dengan daftar harga barang) dan sebagian besar diingat-ingat, sehingga jika harga naik atau turun sulit untuk mengubahnya.  Ketika harga barang naik atau turun harga harus ditulis ulang,

hal tersebut sungguh membuat pemilik kerepotan, jika jumlah barang yang berubah harganya banyak.

 Ketika pembeli banyak, pelayanan yang dilakukan kurang cepat karena terbatasnya penjual (misalnya : pembeli ada 10 orang, sedangkan penjualnya cuma ada 2 orang).

Information.

 Dokumen berupa nota/harga barang masih disimpan dengan kertas, sehingga sulit untuk mencari data barang.

 Proses perhitungan harga dilakukan menggunakan alat bantu hitung (kalkulator), sehingga retan kesalahan perhitungan total pembelian, jika jumlah yang dibeli banyak.

 Tidak terdapat data karyawan, sehingga pemilik kesulitan untuk mengetahui alamat, nomor telepon, dan lain-lain.

(43)

Economics.

 Kerugian biasa terjadi karena harga barang turun, karena barang dibeli waktu harga barang masih mahal, karena tidak adanya penyimpan data.

Control.

 Perubahan harga dilakukan hanya ketika harga naik atau turun, dengan cara merubah harga barang dengan cara ditulis, ketika jumlah barang yang diubah banyak, pemilik akan kesulitan karena tidak adanya satu tempat penyimpanan data.

 Penambahan dan pengurangan barang dilakukan menurut selera konsumen (ketika barang laku terjual, maka stock barang ditambah dan ketika barang tidak lagi laku, maka barang tidak lagi dijual atau dikurangi stocknya) untuk barang baru tergantung banyaknya konsumen yang menanyakan merk barang baru.

Eficiency.

 Perubahan pada penulisan harga barang yang menempel di barang dilakukan dengan cara merubahnya satu-persatu, sehingga hal tersebut belum efisien.

(44)

Services.

 Pembeli yang datang pertama mendapatkan pelayanan pertama, pembeli berikutnya dilayani setelah pembeli pertama selesai.  Ketika banyak pembeli pemilik toko ikut membantu melayani

pembeli.

(45)

3.2.3

Problem Statement

Pernyataan Masalah

Proyek : Sistem Informasi Penjualan, Pembelian, dan Inventori.

Manager Proyek: - Dibuat Oleh : Yunianto Update Terakhir Oleh : - Tanggal Pembuatan: - Tanggal Update Terakhir : -

Pernyataan Singkat Masalah, Kesempatan, atau Perintah

Solusi Diusulkan 1. Sistem lamabelum mampu menangani

perubahan harga barang dengan baik.

Dalam sistem baru akan memuat pencarian data harga barang. 2. Pelayanan yang dilakukan masih

kurang cepat karena keterbatasan penjual.

Tidak dapat dipercepat dengan sistem.

3. Keinginan adanya informasi untuk mencetak bukti transaksi penjualan yang diberikan ke konsumen.

Dalam sistem baru akan dapat mencetak semua proses transaksi penjualan.

4. Bukti transaksi masih dicatat dengan manual dan belum ada backup-nya.

Dalam sistem yang baru akan mencatat data penjualan yang disimpan dalam database sebagai backup-nya

5. Sistem lama tidak mampu melakukan

perhitungan dengan baik. Sistem yang baru dapat menangani perhitungan data dalam jumlah besar.

6. Sistem lama belum terdapat

penyimpanan data karyawan, sehingga menyebabkan pemilik kesulitan mengingat ketika terjadi perubahan data karyawan.

Sistem yang baru akan

menyimpan semua data karyawan kedalam database.

7. Sistem lama sulit dalam mengetahui jumlah barang yang laku.

Sistem baru akan memuat laporan penjualan barang untuk

(46)

3.3 Problem Analysis

3.3.1

Cause Effect

Analysis

And

System

Improvement Objective

MASALAH, KESEMPATAN, TUJUAN, DAN HAMBATAN

PROYEK : MANAGER PROYEK:

DICIPTAKAN OLEH: DIPERBAHARUHI OLEH: -

TANGGAL DICIPTAKAN: TANGGAL DIPERBAHARUHI: -

ANALISA PENYEBAB DAN AKIBAT

TUJUAN MEMPERBAIKI SISTEM

MASALAH PENYEBAB

DAN AKIBAT TUJUAN SISTEM BATASAN SISTEM 1. Kesulitan mengingat harga barang

1.Harga barang sering berubah. Akibatnya : sering terjadi kesalahan harga. 2.Pemilik

kesulitan mengingat harga barang dengan cepat. Akibatnya : terjadinya antrian panjang. 1. Memberikan pelayanan secara optimal kepada konsumen dalam proses penjualan. 2. Membuat

karyawan dan pemilik toko untuk tidak mengingat-ingat harga barang

berulang kali.

1.Semua data harga barang harus sudah

dimasukkan.

2. Proses penyimpanan data barang belum

dilakukan dengan teratur.

1.Penjual tidak teratur

membuat suatu pengarsipan data

pembelian, penjualan dan inventori barang

Akibatnya :

1.Proses

pencarian data lebih cepat 2.Efek kehilangan data kecil. . 1. Memerlukan pegawai yang khusus

menangani penyimpanan data secara periodik.

(47)

data barang kemungkinan besar akan hilang.

dan perangkat lunak yang mendukung proses penyimpanan data.

3. Penjual salah memberikan harga barang

1. Konsumen mendapat harga barang yang salah. Akibatnya : Konsumen atau pemilik mengalami kerugian. 2. Sering terjadi

kesalahan harga. Akibatnya: Konsumen menjadi kecewa dalam pelayanan yang diberikan Toko Ijo. 1. Memberikan informasi harga barang yang akurat.

1. Memerlukan pegawai yang harus mengurus pencatatan

perubahan harga.

4. Pemilik kesulitan mengetahui barang yang laku.

1. Ítem barang yang banyak. Akibatnya : stok barang tidak diketahui dengan baik. 2. Tidak ada

data barang yang laku terjual. Akibatnya : pemilik kesulitan dalam memesan barang. 1. Memberikan informasi penjualan barang yang laku.

(48)

5. Pemilik kesulitan untuk mencatat bukti transaksi yang banyak 1. Ketika konsumen banyak dan konsumen meminta nota. Akibatnya pemilik harus mencatat nota dengan tangan. 1. Memberikan pencetakan nota tanpa harus ditulis dengan

tangan.

1. Memerlukan perangkat keras dan perangkat lunak yang mendukung proses pencetakan. 6. Pemilik kesulitan mengingat data

karyawan jika terjadi

perubahan karena data karyawan tidak dicatat. 1. Data karyawan mengalami perubahan. Akibatnya : pemilik sering lupa data karyawan berubah 1. Memberikan fasilitas untuk menyimpan data karyawan. Agar pemilik tidak perlu mengingat data karyawan.

1. Memerlukan kesadaran

pegawai untuk mengubah

(49)

3.4 Requirement Analysis

3.4.1 Konteks Diagram

(50)

3.4.2

Use Case

Pemilik Penjualan Pembelian Mencatat data retur pembelian Pencarian data pembelian Barang Mengecek inventori barang Mencatat data barang baru Mengubah data inventori barang Karyawan Membuat data karyawan baru Menghapus data karyawan Pemesanan Barang Mencatat data transaksi penjualan

Mencatat data retur penjualan Pencarian data barang Mencatat data pembelian Menghapus data penjualan Mengubah data karyawan Distributor Mencatat data distributor Mengubah data distributor Pencarian data distributor Penentuan harga jual extends Pemilik Mengubah data password

(51)

Gambar 3.3 Use Case karyawan

3.4.3 Use Case Narrative

Use Case Name : Mencatat data transaksi

penjualan Use Case Type

BussinessRequirements :

□

System Analysis : □

System Design : 

Use Case ID : 1 Prioritys :

Source :

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang pemilik/karyawan

(52)

Precondition : Barang yang diinginkan konsumen sudah ada di inventori. Typical Course of

Events : (a)

Actor Action System Response

Langkah 1 : konsumen datang membawa catatan barang yang dibutuhkannya untuk kemudian diberikan kepada karyawan / pemilik. Langkah 2 : setelah barang yang diinginkan ketemu, konsumen datang ke kasir untuk membayar barang tersebut.

Langkah 2 : pemilik melakukan penginputan data barang yang dibeli oleh konsumen.

Langkah 3 : pemilik / karyawan melakukan proses pencatatan data transaksi penjualan ke dalam sistem.

Langkah 4 : confirmasi pencatatan data transaksi penjualan.

Langkah 5 : sistem akan menyediakan fasilitas untuk mencetak data transaksi penjualan yang telah dilakukan.

Alternate Courses : -

Postcondition : Data penjualan sudah tercatat dalam database.

Use Case Name : Mencatat data transaksi

penjualan Use Case Type

BussinessRequirements :

□

(53)

Source : System Design : 

Description : Use case ini menggambarkan tentang pemilik/karyawan

melakukan proses pencatatan data penjualan barang kepada konsumen ( konsumen membeli barang hanya sedikit). Precondition : Barang yang diinginkan konsumen sudah ada di inventori. Typical Course of

Events : (b)

Langkah 1 : ketika konsumen banyak, dan ada konsumen datang menanyakan barang yang dicarinya (hanya sedikit barang yang dibeli).

Langkah 2 : pemilik memberikan barang yang dicari.

Langkah 3 : konsumen datang ke kasir untuk membayar barang tersebut.

Langkah 4 :

pemilik/karyawan mencatat data yang dibeli dalam kertas.

Langkah 5 : ketika toko sedang sepi, pemilik / karyawan melakukan proses pencatatan data transaksi penjualan ke dalam sistem.

Langkah 4 : confirmasi pencatatan data transaksi penjualan.

Langkah 5 : sistem akan menyediakan fasilitas untuk mencetak data transaksi penjualan yang telah dilakukan.

(54)

Use Case Name : Mencatat data retur penjualan Use Case Type

Bussiness Requirements : □

System Design : 

Source :

Description : Use case ini menggambarkan konsumen yang meretur barang yang dibeli akibat kesalahan yang tidak disenggaja. Precondition : Konsumen salah menerima barang.

Typical Course of Events :

(a)

Langkah 1 : konsumen datang ke toko untuk meretur barang.

Langkah 2 : pemilik/karyawan

melakukan proses pencatatan ke dalam sistem retur penjualan.

Langkah 6 : konsumen menerima barang pengganti.

Langkah 3 : konfirmasi pencatatan data retur penjualan.

Langkah 4 : menampilkan informasi data retur (tanggal retur, kode barang, nama barang, dan lain-lain).

Langkah 5 : sistem akan menyediakan fasilitas untuk mencetak data retur penjualan yang telah dilakukan.

(55)

Use Case Name : Menghapus data penjualan Use Case Type

Source :

Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik melakukan proses penghapusan data penjualan. Karena kesalahan proses transaksi penjualan.

Precondition : Kesalahan data penjualan yang terlajur diproses masih berada dalam database.

Langkah 1 : pemilik melakukan pencarian data penjualan yang ingin dihapus.

Langkah 3 : pemilik memberi perintah kepada sistem untuk menghapus data penjualan.

Langkah 2 : sistem menampilkan data yang dicari oleh pemilik.

Langkah 4 : sistem

menkonfirmasikan perintah yang dilakukan pemilik. Alternate Courses : -

Postcondition : Data penjualan sudah dihapus dari database.

Use Case Name : Pencarian data Barang _{Use Case Type}

(56)

Source : System Analysis : □

Description : Use case ini menggambarkan tentang konsumen yang menanyakan informasi barang yang akan dibelinya dan pemilik/karyawan melakukan pencarian informasi data penjualan tersebut.

Precondition : Daftar barang yang dicari sudah tercatat di inventori. Typical Course of

Events :

Langkah 1 : konsumen menanyakan barang yang dibutuhkannya berikut harganya.

Langkah 2 :

pemilik/karyawan

memasukkan kata kunci pencarian barang yang akan dicari.

Langkah 4 : sistem mencari data dalam database.

Langkah 3 : sistem menampilkan informasi data barang yang dicari.

Postcondition : Konsumen memperoleh informasi barang yang dicari.

Use Case Name : Pemesanan barang Use Case Type

(57)

Description : Use case ini menggambarkan tentang pemilik melakukan pemesanan barang ke distributor.

Precondition : Barang sudah ada di inventori Typical Course of

Events :

Langkah 1 : pemilik mengecek stok barang pada sistem.

Langkah 3 : pemilik

memasukkan data

pemesanan barang.

Langkah 5 : pemilik memberikan data pemesanan yang telah dicetak kepada distributor.

Langkah 2 : sistem menampilkan data stok barang.

Langkah 4 : konfirmasi

penyimpanan data

pemesanan dan pencetakkan data pesanan.

Alternate Courses : - Postcondition : -

Use Case Name : Mencatat data retur pembelian Use Case Type

Source :

(58)

Description : Use case ini menggambarkan tentang pemilik/karyawan yang meretur barang ke suplier. Karena barang rusak/sudah kadarluarsa.

Precondition : Barang diinventori mengalami kerusakan atau kadarluarsa. Typical Course of

Events :

Langkah 1 :

pemilik/karyawan

memasukkan data barang yang akan diretur ke distributor ke dalam sistem.

Langkah 2 : konfirmasi pencatatan data retur.

Langkah 3 : menampilkan informasi data retur (kode barang, nama barang, dan lain-lain).

Langkah 4 : sistem menyediakan fasilitas untuk mencetak data retur pembelian.

Postcondition : Data retur pembelian tercatat dalam database.

Use Case Name : Pencarian data pembelian Use Case Type

Source :

(59)

Precondition : Barang sudah bertambah di inventori Typical Course of

Events :

Langkah 1 :

pemilik/karyawan

memasukkan kata kunci pencarian data pembelian ke dalam sistem.

Langkah 2 : sistem akan menampilkan informasi pencarian data pembelian yang dicari.

Use Case Name : Mencatat data pembelian Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik/karyawan yang mencatat data pembelian barang dari distributor. Precondition : Barang datang dari distributor

Langkah 1 : pemilik / karyawan mencatat data dan informasi barang yang dibeli dari distributor ke dalam sistem.

(60)

pencatatan data pembelian.

Postcondition : Data pembelian disimpan didalam database.

Use Case Name : Mencatat data distributor Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang mendata semua distributor yang melakukan transaksi pembelian dengan toko.

Precondition : Semua pemasok barang yang ada diinventori. Typical Course of

Events :

Langkah 1 : pemilik memasukkan data distributor kedalam sistem.

Langkah 2 : sistem memberikan konfirmasi

penyimpanan data

distributor.

Langkah 3 : data distributor baru ditampilkan pada sistem.

(61)

Postcondition : Data distributor tersimpan dalam database.

Use Case Name : Mengubah data distributor Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang

mengubah data suplier karena terdapat informasi distributor yang berubah

Precondition : Distributor datang memberikan informasi perubahan data distributor.

Langkah 1 : pemilik melakukan pencarian data distributor yang ingin dirubah.

Langkah 3 : pemilik melakukan perubahan data distributor pada sistem.

Langkah 2 : sistem mengecek dalam database

dan memberikan informasi data distributoryang dicari.

Langkah 2 : sistem memberikan konfirmasi perubahan data distributor. Alternate Courses : -

Postcondition : Data distributor telah dirubah.

(62)

Use Case ID : 12 Bussiness Requirements : □

Prioritys :

Source :

Description : Use case ini menggambarkan tentang pemilik yang mencari data distributor untuk kepentingan pemesanan barang. Precondition : pemilik ingin memesan barang, tapi lupa distributornya. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik memasukkan kata kunci pencarian data distributor.

Langkah 2 : sistem menampilkan informasi data distributor yang dicari. Alternate Courses : -

Postcondition : -

Use Case Name : Membuat data karyawan baru Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang membuatkan account kepada karyawan baru agar dapat mengakses sistem.

(63)

Langkah 1 : pemilik menginputkan data-data karyawan baru (nama, alamat, username, passwod, dan lain-lain).

Langkah 2 : konfirmasi pencatatan data karyawan. Langkah 3 : menampilkan informasi data karyawan. Alternate Courses : -

Postcondition : Data karyawan baru tersimpan dalam database.

Use Case Name : Mengubah data karyawan Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang mengubah data karyawan karena pindah rumah, ganti telepon, password dan lain-lain.

Precondition : Data karyawan lama masih tersimpan dalam database. Typical Course of

Events :

Langkah 1 :

pemilik/karyawan

menginputkan data karyawan yang ingin diubah.

(64)

karyawan.

Langkah 3 : menampilkan informasi perubahan data.

Postcondition : Data karyawan telah berubah.

Use Case Name : Menghapus data karyawan Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang menghapus hak akses karyawan karena karyawan yang bersangkutan sudah tidak bekerja lagi di Toko Ijo. Precondition : Data karyawan yang sudah tidak bekerja masih tersimpan

dalam database.

Langkah 1 : pemilik memilih data karyawan yang ingin dihapus.

Langkah 2 : sistem memberikan konfirmasi penghapusan data karyawan. Alternate Courses : -

(65)

Use Case Name : Mengecek data inventori

barang Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang mengecek inventori barang.

Precondition : Pemilik ingin mengetahui informasi inventori barang. Typical Course of

Events :

Langkah 1 : pemilik / karyawan memasukkan kata kunci barang yang akan dicek data inventorinya.

Langkah 2 : sistem menampilkan data inventori yang dicari.

Use Case Name : Mencatat data inventori baru Use Case Type

Source :

(66)

Precondition : Pemilik ingin mencatat data inventori baru. Typical Course of

Events :

Langkah 1 : pemilik mencatat data dan informasi barang baru pada inventori.

Langkah 2 : konfirmasi pencatatan data inventori. Langkah 3 : sistem menampilkan informasi data inventori baru.

Postcondition : Inventori barang bertambah.

Use Case Name : Mengubah data inventori

barang Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang mengubah data inventori barang .

Precondition : Pemilik ingin mengubah data inventori. Typical Course of

Events :

Langkah 1 : pemilik memasukan kata kunci pencarian data inventori

(67)

Langkah 3 : pemilik mengubah data dan

informasi inventori barang. Langkah 4 : konfirmasi pengubahan data inventori.

Postcondition : Inventori barang berubah.

Use Case Name : Mengubah password admin Use Case Type

Source :

Description : Use case ini menggambarkan tentang pemilik yang mengubah password-nya .

Precondition : Pemilik ingin mengubah password admin.

Langkah 1 : pemilik memasukan password lama.

Langkah 3 : pemilik memasukkan data password

baru.

Langkah 2 : sistem menampilkan validasi

password lama.

Langkah 4 : konfirmasi pengubahan data password

(68)

Postcondition : Data password admin berubah.

3.5 Logical design

3.5.1 Diagram Aktivitas

Mencatat data penjualan(a).

(69)

Mencatat data transaksi penjualan(b).

(70)

Mencatat data retur penjualan

Pemilik/karyawan Sistem

Pemilik / karyawan menerima barang yang diretur

Pencatatan data barang yang diretur

Simpan di database ya

tidak

Menampilkan informasi data retur

Pencetakan data retur

(71)

Menghapus data penjualan

Gambar 3.7 Diagram aktivitas menghapus data penjualan.

Pencarian data barang

(72)

Pemesanan barang

(73)

Mencatat data retur pembelian

Gambar 3.10 Diagram aktivitas mencatat data retur barang.

Pencarian data pembelian

(74)

Mencatat data pembelian

Gambar 3.12 Diagram aktivitas pencatatan data pembelian.

Pencatatan data distributor

(75)