penerapan object relational mapping pada pengembangan ... · pengguna linux indonesia-bogor) ......

PENERAPAN OBJECT RELATIONAL MAPPING

PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING

DIAN INDAH SAVITRI

DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

INSTITUT PERTANIAN BOGOR

2008

PENERAPAN OBJECT RELATIONAL MAPPING

PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING

Skripsi

Sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer

pada Fakultas Matematika dan Ilmu Pengetahuan Alam

Institut Pertanian Bogor

Oleh :

DIAN INDAH SAVITRI

G64104035

DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

INSTITUT PERTANIAN BOGOR

2008

Judul : Object Relational Mapping pada Pengembangan Enterprise Resource

Planning

Nama : Dian Indah Savitri

NRP : G64104035

Menyetujui:

Pembimbing I, Pembimbing II,

Wisnu Ananta Kusuma, S.T., M.T. Toto Haryanto, S.Kom

NIP 132 312 485

Mengetahui:

Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam

Institut Pertanian Bogor

Dr. Drh. Hasim, DEA

NIP 131 578 806

Tanggal Lulus:

iv

ABSTRAK

DIAN INDAH SAVITRI. Penerapan Object Relational Mapping pada Pengembangan Enterprise

Resource Planning. Dibimbing oleh WISNU ANANTA KUSUMA dan TOTO HARYANTO.

Enterprise Resource Planning (ERP) merupakan suatu aplikasi terintegrasi yang difokuskan

untuk mengotomasi seluruh aktivitas infrastruktur pada suatu perusahaan. Sistem ERP

menggabungkan proses bisnis antara perusahaan dan pelanggan, perusahaan dengan supplier, dan

proses perhitungan keuangan perusahaan. Semua proses bisnis yang tergabung mengakses pada

sebuah basis data yang terpusat.

Sistem manajemen basis data yang banyak digunakan pada aplikasi ERP adalah basis data

relasional, sedangkan pengembangan aplikasi skala enterprise sebagian besar menerapkan konsep

berorientasi objek. Dengan demikian terdapat ketidaksesuaian antara basisdata relasional yang

digunakan dengan aplikasi yang dikembangkan dan pendekatan berorientasi objek.

Ketidaksesuaian tersebut antara lain terkait dengan aspek granularity, subtypes, identitas, asosiasi,

dan navigasi data.

Pada penelitian ini dilakukan analisis terhadap rancangan aplikasi ERP. Ditemukan

ketidaksesuaian yang meliputi empat aspek, yaitu aspek granularity, identitas, asosiasi, dan

navigasi data. Untuk mengatasi ketidaksesuaian tersebut, diimplementasikan konsep Object

Relational Mapping (ORM). Setiap objek yang akan dipetakan menjadi tabel-tabel pada basis data

relasional dibungkus oleh suatu interface dengan menerapkan konsep design pattern. Hal tersebut

bertujuan untuk memudahkan integrasi dengan lapisan aplikasi.

Implementasi ORM ini dibagi menjadi beberapa tahapan, yaitu: pemetaan Data Transfer

Object (DTO) dengan menghilangkan paradigma ketidaksesuaian antara basis data relasional dan

pemrograman berorientasi objek, membuat fungsi-fungsi akses data dengan mengimplementasikan

DAO pattern, menyederhanakan fungsi akses data dengan memanfaatkan konsep design pattern,

membuat skema basis data, dan menyatukan lapisan persistensi dengan lapisan aplikasi.

Implementasi konsep ORM terbukti dapat menghilangkan ketidaksesuian tersebut. Selain itu

penerapan ORM yang dilengkapi dengan design pattern membuat sistem ERP menjadi lebih

terstruktur dan mudah untuk dikembangkan.

Kata kunci: Object Relational Mapping (ORM), object relational mismatch, basis data relasional,

object oriented, design pattern.

v

RIWAYAT HIDUP

Penulis dilahirkan di Tasikmalaya pada tanggal 23 Juni 1986 sebagai anak pertama dari dua

bersaudara dari pasangan Ana Suparjana dan Dedeh Juliarsih. Penulis menyelesaikan pendidikan

menengah atas di SMU Negeri 1 Tasikmalaya dan lulus pada tahun 2004.

Pada tahun yang sama penulis diterima sebagai mahasiswa Departemen Ilmu Komputer,

Fakultas Matematika dan Ilmu Pengetahuan Alam, Institut Pertanian Bogor. Penulis diterima

melalui jalur Undangan Seleksi Masuk IPB (USMI). Penulis pernah pelaksanaan kegiatan Praktek

Kerja Lapangan di PT. Sigma Karya Sempurna (Balicamp) sebagai Software Tester untuk Proyek

Panin Business Internet Banking.

Selama kuliah penulis aktif dalam beberapa kegiatan kemahasiswaan terutama di

Himpunan Mahasiswa Ilmu Komputer (Himalkom). Pada saat di Himalkom penulis bertugas

sebagai Bendahara 1. Pada tahun 2007 penulis aktif di komunitas KPLI-Bogor (Kelompok

Pengguna Linux Indonesia-Bogor) sebagai Sekretaris. Saat ini penulis aktif sebagai anggota Java

Campus Team di Departemen Ilmu Komputer.

vi

PRAKATA

Puji dan syukur penulis panjatkan kepada Allah SWT atas limpahan nikmat dan hidayah-

Nya sehingga penulis dapat menyelesaikan karya ilmiah ini. Sholawat dan salam semoga

senantiasa tercurah kepada Nabi besar Muhammad SAW, keluarganya, para sahabat, serta para

pengikutnya yang tetap istiqomah mengemban risalah-Nya.

Penulis ingin menyampaikan penghargaan dan terima kasih kepada Bapak Wisnu Ananta

Kusuma, S.T., M.T. selaku pembimbing I, yang telah meluangkan waktunya untuk membimbing

penulis, memberikan ilmu-ilmu yang berharga, serta dukungan selama penelitian ini berlangsung.

Penulis juga mengucapkan terima kasih kepada Bpk. Toto Haryanto, S.Kom. selaku pembimbing

II, yang telah membimbing penulis dan selalu memberikan semangat, serta penulis mengucapkan

terima kasih kepada Bapak Irman Hermadi, S.Kom.,M.S. yang telah bersedia menjadi penguji

dalam pelaksanaan seminar dan sidang.

Kemudian penulis ucapkan terima kasih kepada seluruh keluarga khususnya kepada kedua

orang tua dan Ulfa atas doa, dukungan, kasih sayang, dan pengorbanannya selama ini. Disamping

itu, penulis ingin mengucapkan terima kasih kepada Mas Ifnu yang selalu memberi semangat,

memberi dukungan untuk terus menyelesaikan tugas akhir, dan pengorbanan yang diberikan

selama penelitian ini berlangsung.

Penulis juga mengucapkan terima kasih kepada Halida dan Dany yang telah memberikan

banyak pengalaman berharga selaku rekan seperjuangan dalam menyelesaikan aplikasi penelitian

ini. Upacan terima kasih dari penulis teruntuk Bang Robi dan Kak Ria yang selalu memberikan

masukan dan meluangkan waktu untuk berdiskusi ERP. Kepada Dhiku dan Pak Endy, terima kasih

untuk referensi dan tutorial Java-nya.

Kemudian penulis ucapkan terima kasih kepada Dwi, Ina, Heni, Endang dan Tri yang telah

membantu selama penulisan tugas akhir dan memberi dukungan ketika seminar dan sidang. Serta

terima kasih kepada Dita, Vina, Dwi, dan teman-teman “New Arini” lainnya yang telah

memberikan wawasan dan keceriaan kepada penulis. Semua teman-teman ilkomerz’41, terima

kasih untuk canda tawa, persahabatan, dan kebersamaan selama kuliah di Ilkom IPB.

Penulis mengucapkan terima kasih kepada seluruh staf pengajar yang telah memberikan

wawasan serta ilmu yang berharga selama penulis menuntut ilmu di Departemen Ilmu Komputer.

Seluruh staf administrasi dan perpustakaan Departemen Ilmu Komputer yang selalu memberi

kemudahan dalam mengurus segala macam hal berkaitan dengan perkuliahan, serta pihak-pihak

lain yang tidak dapat disebutkan satu-persatu.

Sebagaimana manusia yang tidak luput dari kesalahan, penulis menyadari bahwa karya

ilmiah ini jauh dari sempurna. Namun penulis berharap semoga karya ilmiah ini dapat bermanfaat

bagi siapapun yang membacanya. Semoga tulisan ini dapat bermanfaat khususnya untuk penulis

pribadi, umumnya untuk semua warga Institut Pertanian Bogor.

Bogor, Juni 2008

Dian Indah Savitri

DAFTAR ISI

Halaman

DAFTAR ISI ................................................................................................................................... vii

DAFTAR GAMBAR .....................................................................................................................viii

DAFTAR LAMPIRAN ..................................................................................................................viii

PENDAHULUAN

Latar Belakang ............................................................................................................................. 1

Tujuan Penelitian ......................................................................................................................... 1

Ruang Lingkup Penelitian ........................................................................................................... 1

Manfaat Penelitian ....................................................................................................................... 1

TINJAUAN PUSTAKA

Enterprise Resource Planning ..................................................................................................... 1

Basis Data Relasional .................................................................................................................. 2

Persistent Object ......................................................................................................................... 2

Object Relational mismatch ......................................................................................................... 2

Object Relational Mapping ......................................................................................................... 3

Framework .................................................................................................................................. 3

Design pattern dan JEE pattern ................................................................................................... 3

Model View Controller ................................................................................................................ 4

Declarative Transaction .............................................................................................................. 4

Dependency Injection / Inversion of Control ............................................................................... 5

METODE PENELITIAN .................................................................................................................. 5

Kerangka Pemikiran .................................................................................................................... 5

Studi Literatur .............................................................................................................................. 5

Analisis Kebutuhan ORM ........................................................................................................... 5

Implementasi ORM dan Design Pattern .................................................................................... 5

Evaluasi ....................................................................................................................................... 5

HASIL DAN PEMBAHASAN

Analisis Kebutuhan ORM pada Sistem ERP ............................................................................... 6

1 Deskripsi Umum Aplikasi Ritel ERP ................................................................................. 6

2 Analisis Masalah Ketidaksesuaian...................................................................................... 6

a granularity ..................................................................................................................... 6

b identitas ......................................................................................................................... 6

c asosiasi .......................................................................................................................... 7

d navigasi data .................................................................................................................. 7

Implementasi ORM dan Design Pattern ..................................................................................... 7

1 Melakukan Konfigurasi Basis Data ................................................................................... 7

2 Membuat Class DTO (Data Transfer Object) ................................................................... 7

a Aspek Granularity ......................................................................................................... 8

b Aspek Identitas .............................................................................................................. 8

c Aspek Asosiasi .............................................................................................................. 8

d Aspek Navigasi data .................................................................................................... 10

3 Membuat Fungsi Akses Data. .......................................................................................... 11

4 Penyederhanaan Fungsi Akses Data ................................................................................ 12

5 Membuat Skema Basis Data. ........................................................................................... 13

6 Menyatukan Lapisan Persistensi dengan Lapisan Aplikasi ............................................ 13

Evaluasi ..................................................................................................................................... 14

viii

KESIMPULAN DAN SARAN

Kesimpulan ................................................................................................................................ 14

Saran .......................................................................................................................................... 15

DAFTAR PUSTAKA ..................................................................................................................... 15

LAMPIRAN .................................................................................................................................... 16

DAFTAR GAMBAR

Halaman

1 Mekanisme ORM. .......................................................................................................................... 3

2 Arsitektur MVC (Wahab 2007). ..................................................................................................... 4

3 Diagram Metodologi Penelitian. .................................................................................................... 5

4 Skema pembuatan DTO. ................................................................................................................ 8

5 Pemetaanf asosiasi one-to-one. ...................................................................................................... 8

6 Pemetaan asosiasi one-to-many. ..................................................................................................... 9

7 Pemetaan asosiasi many-to-many ................................................................................................. 10

DAFTAR LAMPIRAN

Halaman

Lampiran 1 Daftar Tabel ................................................................................................................. 17 Lampiran 2 Class Diagram Data Transfer Object .......................................................................... 19 Lampiran 3 ER Diagram ................................................................................................................. 26 Lampiran 4 Kamus data .................................................................................................................. 30 Lampiran 5 Teknik Inversion of Controls ....................................................................................... 46 Lampiran 6 Declarative Transaction untuk setiap modul ............................................................... 53 Lampiran 7 Contoh Kode Program ................................................................................................. 54

1

PENDAHULUAN

Latar Belakang

Enterprise Resource Planning (ERP)

merupakan suatu aplikasi terintegrasi yang

difokuskan untuk mengotomasi seluruh

aktivitas infrastruktur dalam suatu

perusahaan. Sistem ERP menggabungkan

proses bisnis antara perusahaan dan

pelanggan, perusahaan dengan supplier, dan

proses perhitungan keuangan perusahaan.

Semua proses bisnis yang tergabung

mengakses pada sebuah basis data yang

terpusat (Parr 2000).

Sebagian besar aplikasi yang berskala

enterprise dikembangkan dengan

pendekatan berorientasi objek menggunakan

three-tier-architecture yang terdiri atas

lapisan presentasi, lapisan aplikasi, dan

lapisan basis data (Rashid et al. 2002).

Sementara itu, sistem manajemen basis data

yang banyak digunakan sekarang ini adalah

basis data relasional. Dengan demikian,

terdapat ketidaksesuaian (mismatch

paradigm) antara basis data relasional yang

digunakan dan aplikasi yang dikembangkan

dengan pendekatan berorientasi objek.

Ketidaksesuaian tersebut antara lain aspek

granularity, subtypes, identitas, asosiasi,

dan navigasi data (Bauer & King 2007).

Untuk mengatasi masalah ini Nugraha

(2005) melakukan penelitian mengenai

konsep ORM (Object Relational Mapping)

yang berfungsi memetakan antara class dan

tabel. Pada prinsipnya, penelitian tersebut

menunjukan bahwa Object Relational

Mapping (ORM) adalah sebuah solusi yang

dapat menjembatani paradigma

ketidaksesuaian antara sistem basis data

relasional dan pengembangan aplikasi

berorientasi objek.

Namun demikian Nugraha (2005) hanya

membatasi penelitiannya pada aspek

pemetaan dan tidak diimplementasikan pada

aplikasi yang utuh. Pada penelitian ini,

dilakukan analisis terhadap aplikasi Ritel

ERP yang dikembangkan Ernita (2008)

untuk menunjukan adanya ketidaksesuaian

(mismatch) tersebut. Selanjutnya akan

diimplementasikan konsep ORM untuk

menghilangkan ketidaksesuaian tersebut

serta penerapan konsep design pattern yang

berfungsi dalam proses penyatuan dengan

lapisan aplikasi.

Tujuan Penelitian

Tujuan dari penelitian ini adalah:

1 Menganalisis ketidaksesuaian yang

muncul dari rancangan sistem Ritel ERP

yang dikembangkan Ernita (2008) dan

basis data relasional yang digunakan. 2 Menerapkan konsep ORM untuk

mengatasi masalah ketidaksesuaian

tersebut.

3 Memanfaatkan konsep design pattern

dalam pengaksesan basis data oleh

lapisan aplikasi.

Ruang Lingkup Penelitian

Ruang lingkup penelitian ini adalah :

1 Membangun lapisan Model untuk

aplikasi Ritel ERP dengan menerapkan

konsep ORM dengan menggunakan satu

framework yang telah ada tanpa

membandingkan dengan framework

ORM lain.

2 Menerapkan konsep ORM pada aplikasi

Ritel ERP tetapi tidak disertai konsep

untuk manajemen backup data dan

pengelolaan data yang sudah tidak

terpakai.

Manfaat Penelitian

Penelitian ini diharapkan dapat

bermanfaat dalam pemeliharaan dan

pengelolaan manajemen basis data pada

pengembangan aplikasi ERP selanjutnya.

Selain itu, penerapan ORM dapat

menghemat koneksi pada server basis data

sehingga aplikasi ERP yang dikembangkan

lebih optimal.

TINJAUAN PUSTAKA

Enterprise Resource Planning

Enterprise Resource Planning (ERP)

adalah suatu aplikasi terintegrasi yang

difokuskan untuk mengotomasi seluruh

aktivitas infrastruktur perusahaan. Aplikasi

ERP menggabungkan proses bisnis antara

perusahaan dan pelanggan, perusahaan dan

supplier, dan proses perhitungan keuangan

perusahaan. ERP mengotomasi proses bisnis

perusahaan baik dari segi produksi,

distribusi, keuangan, waktu, dan sumber

daya manusia (Parr 2000).

2

Inti modul ERP antara lain

(Rashid et al. 2002) :

Manajemen akuntasi dan keuangan.

Manajemen manufacturing dan produksi.

Manajemen transportasi, penjualan dan

distribusi.

Manajemen sumber daya manusia

Supply Chain Management (SCM).

Customer Relationship Management

(CRM).

Pengembangan aplikasi ERP

menggunakan three-tier architecture yang

terdiri atas (Rashid et al. 2002):

Lapisan presentasi berisi Graphical User

Interface (GUI) atau browser untuk data

entry atau untuk melakukan akses

terhadap fungsi sistem.

Lapisan aplikasi berisi business rules,

fungsi, logika, perlakuan program

terhadap data yang diterima/ ditransfer

dari/ke server basis data.

Lapisan basis data berisi fungsi

manajemen data transaksi termasuk di

dalamnya metadata.

Basis Data Relasional

Basis data merupakan sekumpulan data

atau entitas beserta deskripsinya yang secara

logika berelasi, dibuat untuk memenuhi

kebutuhan informasi suatu organisasi serta

dapat digunakan bersama-sama. Tujuan

utama basis data adalah mengelola dan

mengolah data yang begitu kompleks secara

mudah, cepat dan efisien untuk berbagai

kebutuhan (Connolly & Carolyn 2002).

Pada basis data relasional, relation

berarti tabel, sehingga data disimpan dalam

bentuk tabel-tabel. Relation digunakan untuk

menyimpan informasi yang ditunjukan

dalam basis data. Setiap tabel mempunyai

atribut yang mewakili nama kolom dari tabel

tersebut. Konsep relation hanya berlaku

terhadap struktur lojik tidak mencakup

struktur fisik (Connolly & Carolyn 2002).

Persistent Object

Dalam pengembangan sistem, persistent

object didefinisikan sebagai objek yang

dihasilkan dari suatu sistem dan dapat

disimpan dalam waktu yang lama bahkan

bersifat permanen (Peak & Heudecker

2006).

Persistent object bisa disimpan dalam

bentuk basis data relasional, file system

dalam harddisk, file XML, Web Service,

ODBMS (Object Data Base Management

System), dan LDAP. Media penyimpanan

persistent object yang paling banyak

digunakan dalam pengembangan perangkat

lunak adalah basis data relasional. Hal ini

disebabkan pembuatan dan pengaksesan

basis data pada sistem manajemen basis data

relasional relaif mudah (Peak & Heudecker

2006).

Persistent object memudahkan proses

penyimpanan dan pengaksesan data.

Persistent object bersifat abstrak karena

dapat menyembunyikan detail bagaimana

suatu data disimpan dan diakses, sehingga

seakan-akan prosesnya secara detail tidak

terlihat oleh objek lainnya

(Peak & Heudecker 2006).

Object Relational mismatch

Object Relational Mismatch adalah

ketidaksesuaian yang terjadi disebabkan

adanya perbedaan antara aplikasi yang

diimplementasikan dengan pendekatan

berorientasi objek dan penyimpanan data

yang menggunakan sistem basis data

relasional. Ketidaksesuaian tersebut meliputi

aspek:

1 Granularity

Ketidaksesuaian pada aspek granularity

menyangkut pada pemecahan entitas

menjadi atribut-atribut yang lebih

kompleks. Pada basis data relasional

tidak dikenal tipe data yang didefinisikan

oleh pengguna (user-defined-data-type).

Sebagai contoh class Person

mempunyai atribut address dengan

tipe data address. Pada basis data

relasional tidak mungkin mendefinisikan

kolom address dengan tipe data

address juga. Hal yang paling

mungkin dilakukan adalah memecah

address menjadi street_address,

city_address, zipCode_address

dan tetap dimasukan ke dalam tabel

Person.

2 Subtypes

Ketidaksesuaian pada aspek subtypes

adalah pembeda antara superclass dan

subclass. Pada pemrograman berorientasi

objek dikenal istilah inheritance

(pewarisan) dari class parent kepada

class child, sedangkan pada basis data

relasional tidak dikenal proses pewarisan

antar tabel.

3 Identitas Ketidaksesuaian pada aspek identitas

adalah adanya perbedaan pengenal

3

identitas antara objek dan tabel. Pada

objek terdapat dua cara untuk

membedakan objek yang satu dengan

objek lainnya, yaitu dengan

menggunakan fungsi antara lambang

sama dengan (==) dan method

equals(). Lambang sama dengan

(==)merujuk pada alamat memori yang

sama, sedangkan method equals()

merujuk pada nilai secara lojik yang

sama. Akan tetapi pada basis data yang

membedakan tabel satu dengan tabel

yang lain adalah primary key.

4 Asosiasi

Ketidaksesuaian pada aspek asosiasi

meliputi hubungan dua entitas yang

memiliki keterhubungan. Pada objek,

penghubung dua entitas tersebut dikenal

sebagai references sedangkan pada basis

data relasional dikenal dengan foreign

key. Asosiasi antarentitas terdiri atas:

one-to-one, one-to-many, dan many-to-

many.

5 Navigasi data

Ketidaksesuaian pada aspek navigasi

data meliputi proses pengaksesan suatu

objek dari objek lain. Pada basis data

relasional navigasi data dilakukan

menggunakan query join sedangkan

pada pendekatan berorientasi objek

dilakukan dengan memanggil suatu

method getter. Navigasi dibagi dua

macam berdasarkan arahnya, antara lain:

directional dan bidirectional

(Bauer & King 2007).

Object Relational Mapping

Object Relational Mapping merupakan

suatu teknik untuk memetakan dari

persistent object pada aplikasi ke dalam

tabel pada basis data secara otomatis dan

transparan. Mekanisme ORM dapat dilihat

pada Gambar 1. ORM menggunakan

metadata untuk mendeskripsikan pemetaan

antara objek dan basis data (Bauer & King

2007).

ORM berperan sebagai lapisan model

dalam MVC pattern. Model adalah sebuah

lapisan yang paling dekat dengan sumber

data, baik itu berasal dari basis data,

webservice, maupun file system. ORM

merupakan solusi yang dapat mengatasi

ketidaksesuaian yang terjadi akibat adanya

perbedaan antara aplikasi yang

diimplementasikan dengan pendekatan

berorientasi objek dan penyimpanan data

dengan menggunakan sistem basis data

relasional. Teknologi ORM ada beberapa

macam, seperti Toplink dari Oracle, Kodo

dari Bea System, dan Hibernate dari

RedHat.

Gambar 1 Mekanisme ORM

(Thamura et al. 2007).

Framework

Framework adalah aplikasi semi-

complete yang dapat digunakan untuk

membuat aplikasi lain yang lebih spesifik

(Husted 2003). Framework yang ideal

merupakan intisari dari pendekatan terbaik

dalam pengembangan perangkat lunak.

Apabila suatu aplikasi dikembangkan

menggunakan framework maka harus

mengadopsi semua mekanisme dan

ketentuan yang ditetapkan pada framework

tersebut. Suatu framework mempunyai

sekumpulan file library khusus. Alasan

pengembangan sebuah framework adalah

dimungkinkannya penggunaan kembali

perangkat lunak dalam pengembangan

selanjutnya.

Salah satu framework ORM adalah

Hibernate. Hibernate adalah salah satu ORM

framework open source yang dikembangkan

untuk menangani masalah data persistence

pada lingkungan Java. Hibernate terdiri atas

dua versi yaitu Hibernate Core dan

Hibernate Annotation. Hibernate Core

menggunakan file XML untuk melakukan

pemetaan terhadap objek-objek tabel pada

basis data, sedangkan Hibernate Annotation

menggunakan Java Annotation untuk

mapping terhadap basisdata.

Implementasi Hibernate pada kode

program Java menggunakan HQL

(Hibernate Query Language) (Bauer dan

King 2007). Sebelum melakukan query

terhadap basisdata, terdapat beberapa

konfigurasi yang harus dilakukan, antara

lain menentukan dialect (jenis DBMS) yang

digunakan, class driver, dan file koneksi.

database

Table1

Table2

Table3O

R M

apping

4

Controller

Model View

Manipulasi Interaksi

Ditampilkan

Design pattern dan JEE pattern

Design pattern adalah pola atau unsur-

unsur rancangan yang seringkali muncul

pada berbagai jenis sistem. Design pattern

merupakan katalog permasalahan yang

sering muncul beserta solusi yang sudah

teruji dalam perancangan sistem (Gamma et

al. 1995). Design pattern yang sering

dijadikan studi adalah design pattern yang

berasal dari Gang of Four (GoF) yaitu, Erich

Gamma, Richard Helm, Ralph Johnson, dan

John Vlissides.

GoF mengumpulkan pattern yang biasa

dipakai dalam membangun sebuah sistem

menjadi suatu katalog lengkap yang dapat

dipakai dalam memecahkan berbagai

masalah dalam pembangunan sebuah sistem.

Dengan mengetahui deskripsi lengkap dari

suatu permasalahan maka akan dapat dengan

mudah diketahui pattern apa yang cocok

sebagai solusi dari permasalahan tersebut

dan ketika menghadapi masalah yang sama

atau mirip maka pattern tersebut dapat

digunakan kembali (Wahab 2007).

Design pattern yang digunakan pada

penelitian ini antara lain (Gamma et al.

1995) :

a. Singleton adalah pola yang mengatur

suatu objek yang hanya mempunyai satu

instansiasi selama aplikasi berjalan.

b. Proxy adalah pola yang merancang

suatu objek untuk mewakili kontrol atau

akses objek lain dan bertindak seolah-

oleh objek tersebut melakukannya.

c. Façade adalah pola yang

menyederhanakan objek-objek yang

terlihat rumit ke dalam sebuah interface.

d. Factory method adalah pola untuk

mengenkapsulasi suatu objek dan

diinstasiasi satu kali untuk digunakan

berulang-ulang oleh objek.

Selain GoF, juga terdapat Gang of Three

(GoT) yang terdiri atas Deepak Alur, John

Crupi, dan Dan Malks. JEE pattern

sebenarnya mengacu kepada design pattern

berdasarkan GoF dan memiliki fungsi yang

sama yaitu sebagai katalog permasalahan

dan solusi yang sudah teruji dalam

pengembangan spesifik aplikasi JEE. JEE

pattern yang dipakai pada penelitian ini

adalah DTO (Data Transfer Object) dan

DAO (Data Access Object).

Data Transfer Object (DTO) pattern

adalah pola yang mengenkapsulasi bisnis

data dan mengirimkannya secara sekaligus

dalam satu waktu (Alur et al. 2003). DTO

pattern juga berfungsi sebagai jembatan

penghubung antarlapisan dalam aplikasi.

Dengan pola ini proses perpindahan data

menjadi sederhana dan terintegrasi. Data

Access Object (DAO) pattern adalah pola

yang mengenkapsulasi data akses dan

manipulasi ke dalam lapisan yang berbeda

kemudian diimplementasikan dengan

membuat sebuah objek yang bersifat abstrak

dan mengenkapsulasi seluruh akses data.

(Alur et al. 2003).

Model View Controller

Model View Controler (MVC) pattern

adalah pola yang memisahkan antara

tampilan antarmuka (View), proses bisnis

(Controller), dan objek data (Model)

(McGovern 2003). Gambar 2 menunjukan

struktur Model View Controller pattern

(Wahab 2007). Lapisan Model merupakan

proses bisnis utama. Di dalamnya terdapat

kode untuk persistensi data dan proses

bisnis. Secara singkat, Lapisan Model ini

menangani isi dari aplikasi. Di lapisan ini

diputuskan data yang akan diberikan pada

client.

Sementara itu, lapisan View menangani

masalah-masalah yang berkaitan dengan

tampilan. Lapisan ini hanya melakukan

pengaturan terhadap data agar tampilannya

sesuai dengan kebutuhan pengguna. Lapisan

terakhir adalah lapisan Controller, lapisan

ini berfungsi mengatur alur pengguna. Pada

lapisan ini dilakukan pemrosesan request

untuk menentukan proses bisnis mana yang

akan dieksekusi. Biasanya layer controller

juga digunakan untuk mengatur ijin akses.

Gambar 2 Arsitektur MVC (Wahab 2007).

Declarative Transaction

Declarative Transaction adalah suatu

teknik untuk medeklarasikan semua

transaksi dalam suatu file konfigurasi untuk

menangani semua proses transaksi tanpa

harus membuat kode-kode program untuk

menangani transaksi secara eksplisit. Selain

5

Studi literatur

Analisis

permasalahan

ketidaksesuaian

Perancangan dan

implementasi ORM

dan design pattern

evaluasi

itu mengatur rollback (method dan

exception) apabila terjadi kegagalan

transaksi (Walls & Beidenbach 2005 ).

Dependency Injection / Inversion of

Control

Dependency Injection adalah suatu

konsep yang diterapkan oleh suatu objek

untuk mendapatkan objek lain yang

dibutuhkan tanpa harus mencari dan

memasukan objek tersebut secara eksplisit

(Walls & Beidenbach 2003)

Konsep ini diterapkan dalam Spring

framework. Semua DAO yang didefinisikan

tidak harus menuliskan koneksi basis

datanya secara langsung pada masing-

masing DAO, tetapi cukup memasukkan

koneksinya menjadi suatu konstruktor atau

method setter dalam DAO

(Thamura et al. 2007).

METODE PENELITIAN

Kerangka Pemikiran

Tahap-tahap yang dilakukan pada

penelitian ini diilustrasikan pada Gambar 3.

Penelitian diawali dengan studi literatur

kemudian melakukan analisis

ketidaksesuaian (mismatch) pada aplikasi

Ritel ERP (Ernita 2008) yang memunculkan

kebutuhan ORM. Tahap selanjutnya adalah

merancang dan mengimplementasikan ORM

dan design pattern untuk mengatasi masalah

ketidaksesuian tersebut. Tahap terakhir

adalah melakukan evaluasi hasil

implementasi konsep ORM tersebut.

Gambar 3 Diagram Metodologi Penelitian.

Studi Literatur

Studi literatur diawali dengan

menganalisis ORM framework yang tersedia

di lingkungan JEE. Selain itu, dilakukan

juga studi literatur dengan menganalisis

paper yang terkait.

Analisis Permasalahan Ketidaksesuaian

Aplikasi Ritel ERP (Ernita 2008)

dikembangkan dengan pendekatan

berorientasi objek, sedangkan manajemen

basis datanya menggunakan sistem

manajemen basis data relasional. Oleh

karena itu dilakukan analisis kemungkinan

ketidaksesuaian (mismatch) yang disebabkan

perbedaan paradigma tersebut.

Perancangan dan Implementasi ORM

dan Design Pattern

Pada tahap ini, dilakukan implementasi

ORM dan design pattern untuk

menghilangkan ketidaksesuaian yang

muncul dari tahap analisis. ORM

diimplementasikan menjadi enam tahap,

antara lain:

1 Membuat konfigurasi basis data.

2 Membuat pemetaan Data Transfer

Object (DTO) dengan menghilangkan

paradigma ketidaksesuaian antara basis

data relasional dan pemrograman

berorientasi objek.

3 Membuat fungsi-fungsi akses data

sebagai implementasi dari DAO

pattern, singleton pattern, dan factory

method pattern.

4 Menyederhanakan fungsi akses data

dengan memanfaatkan konsep facade

pattern dan proxy pattern.

5 Membuat skema basis data.

6 Menyatukan lapisan persistensi dengan

lapisan aplikasi.

Evaluasi

Pada tahap evaluasi dilakukan analisis

terhadap hasil implementasi ORM untuk

mengatasi ketidaksesuaian dari rancangan

aplikasi Ritel ERP dan basis data relasional

yang digunakan. Selain itu evaluasi juga

dilakukan terhadap konsep design pattern

yang digunakan.

6

HASIL DAN PEMBAHASAN

Analisis Permasalahan Ketidaksesuaian

Untuk mendapatkan gambaran yang

lebih lengkap terhadap Ritel ERP (Ernita,

2008) yang akan dianalis, berikut ini

diuraikan deskripsi umum ERP untuk

perusahan Ritel tersebut.

1 Deskripsi Umum Aplikasi Ritel ERP

Sistem ERP Ritel yang dikembangkan

Ernita (2008) terdiri atas tiga mudul, antara

lain:

Modul pembelian (Business to Business)

Purchase Requisition (PR) yang dikirim

oleh kepala gudang kepada pihak

pengadaan barang.

Request for Quotation (RFQ) dan

Purchase Order (PO) yang dikirim oleh

bagian pengadaan kepada supplier.

Demand Order (DO) yang dikirim oleh

supplier kepada bagian pengadaan

barang.

Goods Receive yang diperiksa oleh

kepala gudang saat barang diterima.

Manajemen Inventory.

Daftar supplier.

Modul Penjualan (Business-to-Customer)

Daftar katalog yang ditampilkan kepada

pelanggan.

Submodul pemesanan (add to cart)

Konfirmasi tagihan dan pembayaran.

Pengantaran barang.

Daftar pelanggan.

Modul akuntansi

Jurnal buku besar (General Ledger)

Konfirmasi tagihan dan pembayaran.

Account Receivable (AR)

Account Payable (AP)

Manajemen kode akun.

Masing-masing modul pembangun Ritel

ERP tergabung pada satu basis data yang

terpusat.

2 Analisis Masalah Ketidaksesuaian

Aplikasi Ritel ERP membutuhkan basis

data dalam menjalankan proses bisnisnya.

Tiga modul utama pembangun aplikasi Ritel

ERP mengakses pada satu basis data yang

terpusat. Setiap modul mempunyai tabel

master untuk inisialisasi data dari

lingkungan proses bisnis aplikasi Ritel ERP

dan tabel transaksi sebagai hasil transaksi

saat menjalankan proses bisnisnya. Tabel

master dan tabel transaksi yang dirancang

untuk membangun aplikasi Ritel ERP dapat

dilihat pada Lampiran 1.

Pada penelitian ini, aplikasi Ritel ERP

dikembangkan dengan pendekatan

berorientasi objek menggunakan bahasa

pemrograman Java, sedangkan sistem

manajemen basis data yang digunakan

adalah basis data relasional. Oleh karena itu,

terdapat ketidaksesuaian (mismatch) yang

ditimbulkan pada perbedaan konsep

tersebut. Pada penelitian ini, tidak semua

aspek ketidaksesuaian ditemukan. Aspek

ketidaksesuaian yang muncul adalah aspek

granularity, identitas, asosiasi antarentitas,

dan navigasi data.

Uraian berikut memaparkan analisis

ketidaksesuaian pada aspek:

a Granularity

Ketidaksesuaian pada aspek granularity

terjadi karena pada basis data relasional

tidak mengenal user-defined-data-type atau

tipe data yang didefinisikan oleh pengguna.

Ketidaksesuaian aspek granularity yang

ditemukan pada penelitian ini terjadi saat

mendefinisikan properti address pada

entitas Supplier. atribut Address terdiri

atas street, town, state, zip_code.

Aribut address akan dipisahkan menjadi

class berbeda saat pembuatan DTO, akan

tetapi setelah dipetakan tetap masuk sebagai

proserti tabel PU_SUPPLIER.

b Identitas

Ketidaksesuaian pada aspek identitas

terkait dengan perbedaan pengenal identitas

objek dan tabel. Pada objek identitas

dibedakan menjadi nilai dan alamat

memorinya. Oleh karena itu, terdapat dua

notasi yang melambangkan kesamaan suatu

identitas, yaitu lambang sama dengan (==)

dan method equals(). Sebagai contoh

(a == b), berarti variabel a dan b

memegang alamat reference yang sama pada

memori, sedangkan (a.equals(b)),

secara lojik mempunyai nilai yang sama.

Pada basis data relasional, identitas dari

suatu tabel disebut dengan primary key.

Dengan demikian, sering kali terjadi objek

yang secara lojik sama (a.equals(b))

dan mewakili satu baris dalam tabel basis

data, tetapi objek tersebut tidak berada pada

satu lokasi alamat memori yang sama.

7

c Asosiasi

Kebanyakan entitas pada basis data

mempunyai keterhubungan dengan entitas

yang lainnya. Elemen yang menghubungkan

kedua tabel tersebut ditandai dengan foreign

key.

Elemen penghubung dua objek ditandai

dengan sebuah reference object.

Permasalahannya adalah reference object

bergantung pada arah dari asosiasinya

(direction of relationship). Apabila asosiasi

antara dua objek terjadi pada dua arah, maka

harus didefinisikan dua kali pada setiap

classnya. Akan tetapi foreign key pada tabel

relasional tidak mengenal arah dari

asosiasinya, karena asosiasi antara dua tabel

dihubungkan dengan tabel join.

Ketidaksesuaian pada aspek asosiasi

meliputi relasi one-to-one, one-to-many, dan

many-to-many. Masing-masing asosiasi

antarentitas bisa dilihat pada class diagram

dan ER diagram pada Lampiran 2 dan

Lampiran 3.

d Navigasi data

Ketidaksesuaian pada aspek navigasi

terkait dengan masalah bagaimana

mengakses suatu objek yang berasal dari

objek lain. Menurut arahnya, navigasi data

terbagi menjadi dua macam, yaitu:

unidirectional dan bidirectional. Pada

konsep pemrograman berorientasi objek

konsep arah navigas menentukan suatu

objek dapat diakses melalui objek lain,

sedangkan pada basis data relasional konsep

arah navigasi tidak mempengaruhi proses

pengaksesan data dari tabel lain.

Pada konsep pemrograman berorientasi

objek, proses akses properti objek dari objek

lain bisa langsung menggunakan method

getter. Lain halnya dengan basis data

relasional, properti yang menjadi

penghubung antara dua tabel yang berelasi

yaitu foreign key.

Perancangan dan Implementasi ORM

dan Design Pattern

Setelah ditemukan empat aspek

ketidaksesuaian tersebut diimplementasikan

ORM. Selain itu juga diterapkan design

pattern untuk menghilangkan

ketidaksesuaian yang muncul pada tahap

analisis tersebut, meliputi:

1 Melakukan Konfigurasi Basis Data

Tahap konfigurasi merupakan tahap awal

sebelum melakukan akses terhadap basis

data. Konfigurasi basis data disimpan pada

file jdbc.properties. Isi dari file

jdbc.properties adalah sebagai berikut:

1 jdbc.username=root

2 jdbc.password=admin

3 jdbc.url=jdbc:mysql://localhost:

4 3306/erp

5 jdbc.driver=com.mysql.jdbc.Driver

6 hibernate.dialect=org.hibernate.

7 dialect.MySQL5InnoDBDialect

8 hibernate.show_sql=true

9 hibernate.hbm2ddl.auto=create

10 hibernate.format_sql=true

Baris pertama sampai ke lima merupakan

properti konfigurasi koneksi basis data yang

berisi username, password, host dan port

basis data, dan library koneksi yang

digunakan.

Kode pada baris ke enam menentukan

jenis dialek SQL yang akan dipetakan. Baris

ke delapan adalah properti untuk

menampilkan hasil query yang telah diubah

ke dalam bentuk SQL. Baris ke sembilan

merupakan properti yang berfungsi

mengotomasi pembuatan basis data dari

awal sampai akhir. Dan baris ke sepuluh

untuk menghasilkan query dengan format

SQL.

2 Membuat Class DTO (Data Transfer

Object)

DTO merupakan class yang

merepresentasikan setiap tabel pada basis

data. DTO dibuat berdasarkan UML class

diagram yang telah dirancang. DTO berisi

class JavaBean yang setiap propertinya akan

merepresentasikan atribut-atribut pada tabel.

Skema proses pembuatan DTO

diilustrasikan pada Gambar 4.

8

Gambar 4 Skema Pembuatan DTO.

Ketidaksesuaian yang muncul pada tahap

analisis diatasi oleh ORM pada saat

merepresentasikan class DTO dan diakses

sebagai objek.

Uraian berikut menjelaskan

implementasi konsep ORM untuk mengatasi

ketidaksesuaian pada aspek granularity,

identitas, asosiasi, dan navigasi data.

a Aspek Granularity

Proses pemetaan untuk memecah entitas

menjadi entitas yang lebih kompleks pada

atribut address dalam entitas Supplier

menjadi satu entitas address ditulis sebagai

berikut:

- Class Supplier

1 @Entity

2 @Table(name = "PU_SUPLIER")

3 public class Supplier{ 4 @Embedded

5 private Address address = new

6 Address();

7 }

- Class Address

1 @Embeddable

2 public class Address {

3 private String street;

4 private String city;

5 private String zipCode;

6 }

Properti @Embeddable pada baris

pertama class Address mengindikasikan

bahwa class Address merupakan entitas

yang bisa dilekatkan atau dimasukan ke

dalam entitas lain. Properti @Embedded di

baris ke lima pada class Supplier

menandakan bahwa entitas Address

melekat pada entitas Supplier.

b Aspek Identitas

ORM mengatasi ketidaksesuaian pada

aspek identitas dengan menambah properti

identity pada setiap entitas atau class DTO

seperti pada potongan program berikut:

1 @Entity

2 @Table(name = "IN_ITEM")

3 public class Item{

4 @Id

5 @GeneratedValue(strategy=

6 GenerationType.AUTO)

7 @Column(name="id")

8 private Long id;

9 }

Kode pada baris pertama dan kedua

menandakan bahwa class tersebut mewakili

sebuah entitas pada basis data dengan nama

tabel IN_ITEM.

@Id pada baris ke empat merupakan

properti yang merepresentasikan primary

key, secara lojik properti @Id pada class a

berbeda dengan @Id pada class b. Dengan

demikian pengujian apakah isi class a sama

dengan class b bisa ditulis seperti berikut:

a.getid().equals(b.getId()).

Properti @GeneratedValue (strategy

= GenerationType.AUTO merupakan

pengisian id yang secara otomasi seperti

auto_increment pada tabel relasional.

c Aspek Asosiasi

Asosiasi antara dua entitas terdiri atas

one-to-one, one-to-many, dan many-to-

many. Proses pemetaan asosiasi antara dua

entitas adalah sebagai berikut:

One-to-one

Gambar 5 Pemetaan Asosiasi one-to-one.

Prod_ID Prod_name Unit

price

1 pupuk 100

2 bibit 200

public class Product{

private int id;

private String prodName;

private Double unitPrice;

//getter and setter method

}

product

PK id : int

prod_name : varchar

unit_price : longint

-id : int

-prodName : string

-unitPrice : double

Product

9

Gambar 5 merupakan ilustrasi dari class

Demand yang berasosiasi one-to-one dengan

class Order. Letak foreign key atau join

column ditambahkan pada entitas yang

mempunyai total participation pada asosiasi

yang menghubungkannya.

Pada entitas yang mempunyai asosiasi

dua arah (bidirectional) diperlukan

penambahan properti mappedBy oleh

entitas yang tidak total participation (entitas

partial participation), sedangkan pada

entitas yang mempunyai asosiasi satu arah

(unidirectional) tidak perlu menambahkan

properti mappedBy.

Proses pemetaan dua class Demand dan

class Order merupakan contoh asosiasi dua

arah (association bidirectional) dan class

Demand bersifat total participation.

Pemetaan class Demand dan class Order

dapat dituliskan sebagai berikut:

- Class Order

1 @Entity

2 @Table(name="pu_order")

3 public class Order {

4 @OneToOne (mappedBy="order")

5 private Demand demand;

6 }

- Class Demand

1 @Entity

2 @Table(name="pu_demand")

3 public class Demand {

4 @OneToOne

5 @JoinColumn (name="id_order")

6 private Order order;

7 }

Properti Join Column dimasukan pada

class Demand karena entitas Demand

mempunyai total participation. Dengan

demikian, objek Demand menentukan

asosiasi antara dua entitas tersebut.

Asosiasi one-to-one di atas disebut

biderectional karena masing-masing class

memerlukan reference yang

menghubungkannya. Baris empat dan baris

enam pada class Demand menandakan suatu

reference yang mewakili foreign key dari

entitas Order. Begitu pula pada class

Order, reference yang menghubungkannya

ditulis dengan mappedBy yang dituliskan

pada baris ke empat dan lima. Properti

mappedBy=”order” pada class Order

merujuk pada nama atribut order pada

class Demand.

One-to-many

Gambar 6 Pemetaan Asosiasi one-to-many.

Gambar 6 merupakan ilustrasi class

Requisition yang berasosiasi one-to-

many dengan class RequisitionDetail.

Jadi setiap satu objek Requisition terdiri

atas banyak objek RequisitionDetail.

Seperti halnya asosiasi one-to-one,

asosiasi one-to-many mempunyai join

column yang disimpan pada entitas yang

mempunyai total participation. Akan tetapi

pada asosiasi one-to-many, entitas yang

mempunyai total participation pasti berada

pada entitas yang berkardinalitas many.

Dengan demikian, dapat dikatakan join

column berada pada entitas dengan

kardinalitas many.

Class Requisition berasosiasi one-to-

many dengan class RequisitionDetail.

Apabila asosiasinya bidirectional, maka

dapat dikatakan class

RequisitionDetail berasosiasi many-to-

one dengan class Requisition. Proses

pemetaannya ditulis sebagai berikut:

- Class RequisitionDetail

1 @Entity

2 @Table (name="pu_req_detail")

3 Public class RequisitionDetail {

4 @ManyToOne

5 @JoinColumn (name="id_req")

6 private Requisition requisition;

7 }

- Class Requisition

1 @Entity

2 @Table(name="pu_req")

3 public class Requisition{

4 @OneToMany(mappedBy =

5 "requisition")

6 private List <RequisitionDetail>

7 reqDetail = new ArrayList

8 <RequisitionDetail> ();

9 }

Asosiasi many-to-one di atas bersifat

biderectional, sehingga properti join

10

column berada pada entitas yang

berkardinalitas many yaitu class

RequisitionDetail. Akan tetapi pada

entitas yang berkardinalitas one

ditambahkan properti mappedBy sebagai

reference.

Properti asosiasi dan reference dalam

class RequisitionDetail ditulis pada

baris empat dan baris lima. Pada class

PurchaseRequisition, reference yang

menghubungkannya ditulis dengan

mappedBy seperti pada baris empat sampai

baris delepan.

Apabila asosiasinya unidirectional,

properti mappedBy pada class

Requisition dihilangkan. Properti

mappedBy = “requisition” merujuk

kepada atribut “requisition” pada class

RequisitionDetail.

Many to many

Gambar 7 Pemetaan Asosiasi many-to-many.

Gambar 7 merupakan ilusrasi class

Group berasosiasi many-to-many dengan

class Modul. Kedua entitas yang berasosiasi

many-to-many dihubungkan oleh reference

berupa join tabel. Join tabel memiliki

dua buah atribut foreign key yang berasal

dari masing-masing entitas.

Atribut join tabel dimasukan pada

entitas yang memilki total participation

pada asosiasi tersebut. Properti mappedBy

ditambahkan kepada entitas partial

participation apabila asosiasinya dua arah

(bidirectional), sedangkan pada entitas yang

mempunyai asosiasi satu arah

(unidirectional) tidak perlu menambahkan

properti mappedBy.

Proses pemetaan asosiasi di atas

merupakan asosiasi dua arah (association

bidirectional) dan entitas Modul mempunyai

total participation. Pemetaan class Group

dan class Modul dituliskan seperti berikut:

- Class Group

1 @Entity

2 @Table(name = "ad_group")

3 public class Group {

4 @ManyToMany(mappedBy=

5 "groups")

6 private List <Modul>

7 moduls = new ArrayList

8 <Modul>();

9 }

- Class Modul

1 @Entity

2 @Table(name="ad_modul")

3 public class Modul {

4 @ManyToMany

5 @JoinTable (name =

6 "ad_modul_group",

7 joinColumns={

8 @JoinColumn(name=

9 "id_ad_modul")},

10 inverseJoinColumns={

11 @JoinColumn(name=

12 "id_ad_group")})

13 private List <Group> groups =

14 new ArrayList < Group>();

15 }

Peoperti Join table dimasukan pada

properti yang mempunyai total participation

yaitu class Modul. Objek Modul

menentukan asosiasi pada kedua entitas

tersebut.

Asosiasi many-to-many di atas bersifat

biderectional karena masing-masing class

memerlukan reference yang

menghubungkannya. Properti many-to-many

pada class Modul ditulis pada baris empat.

Kemudian reference yang

menghubungkannya berupa join table

yang terdiri atas identity dari masing-masing

entitas. Properti join table ditulis pada

baris lima sampai empat belas dalam class

Modul. Dalam class Group, reference yang

menghubungkannya ditulis pada baris empat

sampai baris delapan. Properti

mappedBy=”groups” pada class Group

merujuk pada nama atribut groups pada

class Modul.

Hasil pemetaan dari asosiasi many-to-

many antara dua class tersebut adalah dua

tabel hasil transformasi dari objek yaitu

AD_MODUL dan AD_GROUP kemudian satu

tabel asosiasi AD_MODUL_GROUP.

d Aspek Navigasi data

Pada konsep pemrograman berorientasi

objek, proses akses properti objek dari objek

11

lain bisa langsung menggunakan method

getter. Contoh:

- Class Item

1 @Entity

2 @Table(name = "IN_ITEM")

3 public class Item {

4 @ManyToOne

5 @JoinColumn(name="id_brand")

6 private Brand brand;

7 }

Class Item mempunyai variabel brand

dengan tipe data Brand seperti ditulis pada

baris ke enam. Untuk mengakses nilai

brand dengan tipe data Brand pada class

Item menggunakan method getter seperti

berikut:

invItem.getInvProdBrand.getName();

Apabila arah navigasinya unidirectional,

maka tidak terdapat properti entitas Item

pada class Brand, sehingga class Brand

tidak bisa mengakses properti entitas Item.

Tetapi apabila arah navigasinya

bidirectional, maka pada class Brand

terdapat properti entitas Item seperti

berikut:

- Class Brand

1 @Entity

2 public class Brand {

3 @OneToMany(mappedBy="brand")

4 private List <Item> item = new

5 ArrayList<Item>();

6 }

Properti mappedBy pada baris ke tiga

menandakan bahwa class tersebut

mempunyai asosiasi bidirectional. Untuk

mengakses variabel item dengan tipe data

Item dari class Brand menggunakan

method getter seperti berikut:

invProdBrand.getInItem.getName();

Basis data relasional tidak mengenal

konsep arah navigasi dalam mengakses data.

Properti yang menjadi penghubung antara

dua tabel yang berelasi yatiu foreign key.

Tabel ITEM dan BRAND mempunyai relasi

one-to-many kemudian foreign key berada

pada tabel ITEM. Selama ada foreign key

yang menghubungkan kedua tabel, proses

query yang melibatkan kedua tabel bisa

dijalankan.

Query berikut merupakan query untuk

mengakses properti item dengan

berdasarkan id_brand pada tabel ITEM.

Select * from IN_ITEM i left

outer join IN_PROD_BRAND pb on

i.id=pb.id where i.id=123

Properti left outer join menandakan

bahwa foreign key berada pada tabel ITEM.

3 Membuat Fungsi Akses Data

Pada penelitian ini, DAO pattern

digunakan untuk proses enkapsulasi fungsi

untuk mengakses data ke dalam lapisan yang

berbeda, sehingga aplikasi tidak perlu

mengetahui detail proses suatu data diakses.

DAO berisi method (fungsi) untuk

mengakses dan memanipulasi data. Pada

penerapannya, DAO dapat

diimplementasikan dengan native query atau

bahasa query basis data relasional (Structure

Query language). DAO juga dapat

diimplementasikan dengan konsep ORM

dengan menggunakan HQL (Hibernate

Query Language).

Proses pembuatan fungsi-fungsi akses

dan manipulasi data memanfaatkan konsep

design pattern, yaitu factory method dan

singleton. Sebelum melakukan akses dan

manipulasi data, terlebih dulu dibuat objek

dataSource yang berisi referensi dari

properti koneksi basis data. DataSource

memanggil referensi properti koneksi basis

data yang ada pada file konfigurasi

jdbc.properties, antara lain: username,

password, server dan port, nama url basis

data, dan jenis driver RDBMS. Objek

dataSource dan semua objek DAO hanya

diinstansiasi satu kali selama aplikasi

berjalan. Objek dataSource dimasukan ke

setiap DAO ketika DAO diinstansiasi,

sehingga proses koneksi basis data tidak

dilakukan secara berulang-ulang melainkan

cukup dipanggil apabila diperlukan.

Framework ORM yang digunakan untuk

proses pengaksesan data pada penelitian ini

adalah Hibernate. DAO diimplementasikan

menggunakan HQL (Hibernate Query

Language). DAO berisi method untuk

mengakses dan memanipulasi data seperti

create, update, delete, insert, select, dan

join.

Pada penelitian ini, proses pembuatan

objek dataSource dan proses memasukan

dataSource ke dalam semua DAO

dilakukan menggunakan Spring Framework

dengan teknik Inversion of Control (IoC).

Teknik IoC dalam pembuatan objek

12

dataSource dapat dilihat pada Lampiran

5.

Selain objek dataSource, objek yang

diperlukan untuk mengakses data

menggunakan ORM adalah objek

sessionFactory. Seperti halnya objek

dataSource, objek sessionFactory

bersifat singleton, jadi objeknya hanya

dibuat sekali sepanjang aplikasi berjalan.

Objek sessionFactory dipanggil oleh

setiap class DAO yang mengakses basis

data.

SessionFactory membuat objek

session yang diperlukan untuk proses

transaksi yang berlangsung saat mengakses

data. Session merupakan objek yang

hanya sekali pakai, digunakan untuk

melakukan transaksi basis data dan setelah

selesai transaksi, session langsung ditutup.

Siklus hidup objek session berbeda

dengan objek sessionFactory,

sessionFactory dibuat sekali sepanjang

aplikasi berjalan, sedangkan session

dibuat selama proses suatu transaksi

berlangsung. Session bertanggungjawab

selama proses transaksi, session tidak

bisa ditutup sebelum transaksi berhasil dan

session akan melakukan rollback apabila

transaksi gagal.

Pada penelitian ini, proses pembuatan

sessionFactory dan proses memasukan

objek sessionFactory ke dalam semua

DAO dilakukan menggunakan Spring

framework dengan teknik Inversion of

Control (IoC) seperti halnya pada

pembuatan dan penggunaan dataSource.

Teknik IoC untuk sessionFactory dapat


Objek session dibuat oleh class

HibernateDaoSupport melalui method

getHibernateTemplate. Method

getHibernateTemplate bertujuan

membersihkan lapisan aplikasi dari kode

pengaksesan data yang berulang-ulang.

Method getHibernateTemplate

membuat kode program untuk penyimpanan

objek ke dalam basis data menjadi sebagai

berikut:

public class CartDaoHibernate extends

HibernateDaoSupport{

public void save(Cart cart) {

getHibernateTemplate().saveOr

Update(cart);

}

}

Kode program untuk pengambilan objek

dari basis data ditulis sebagai berikut:

Mengambil objek cart sesuai dengan

id tertentu

public Cart getById(Long cartId) {

Cart cart = (Cart)

getHibernateTemplate().

load(Cart. class, cartId);

getHibernateTemplate().initialize

(cart);

return cart;

}

Mengambil objek cart berdasarkan

status yang sedang aktif.

Public Cart getByStatus (String

status){

Cart cart = (Cart) getHibernate

Template.find(“from Cart c where

c.status=?”, “active”);

return cart;

}

Mengambil objek detailCart

berdasarkan cart tertentu.

Public DetailCart getByCart (Cart

Cart){

DetailCart detailCart = (Detail

Cart) getHibernateTemplate.find(“from

CartDetail cd left join fetch

cd.cart”);

return detailCart;

}

Mengambil semua objek cart.

public List<Cart> getAll() {

return getHibernateTemplate().

find("from Cart");

}

Kode program untuk menghapus objek

cart:

public void delete(Cart cart) {

getHibernateTemplate().delete

(cart);

}

4 Penyederhanaan Fungsi Akses Data

Aplikasi Ritel ERP pada penelitian ini

terdiri atas 50 class DTO yang masing-

masing mempunyai interface DAO untuk

akses dan manipulasi data seperti insert,

select, atau delete. Agar mudah diakses,

semua DAO dikumpulkan berdasarkan

submodul ERP ke dalam interface Service.

Interface Service merupakan

implementasi dari facade pattern, yaitu

menyederhanakan fungsi-fungsi yang

terlihat rumit dengan mengelompokkan

fungsi-fungsi tersebut ke dalam beberapa

interface sehingga menghasilkan fungsi

yang lebih sederhana dan mudah digunakan.

Proses penyederhanaan 50 class DTO

menghasilkan tujuh interface Service,

13

antara lain AccountPayableService,

AccountReceivableService, Admin

Service, GeneralLedgerService,

InventoryService, OrderService, dan

PurchaseService. Proses memasukan

DAO ke dalam Service menggunakan

teknik Inversion of Control oleh Spring

Framework. Teknik IoC untuk Service

dapat dilihat pada Lampiran 6.

Implementasi dari semua DAO pada

Service dituliskan sebagai berikut:

public class OrderServiceImpl

implements OrderService {

DebiturDao orderDebiturDao;

CartDao orderCartDao;

}

Objek Service adalah properti yang

akan diakses oleh lapisan aplikasi dalam

proses pengaksesan basis data. Akan tetapi,

sebelumnya dilakukan teknik Declarative

Transaction terhadap Service dengan

menerapkan konsep proxy pattern, yaitu

pola yang merancang suatu objek mewakili

kontrol atau akses objek lain bertindak

seolah-olah objek tersebut melakukannya

Declarative Transaction merupakan

suatu teknik untuk medeklarasikan semua

transaksi dalam suatu file konfigurasi untuk

menangani semua proses transaksi tanpa

harus membuat kode-kode program untuk

menangani transaksi secara eksplisit. Proses

Declarative Transaction ditulis pada file

hibernate.ctx.xml.

Proses Declarative Transaction dimulai

dengan mengatur transaksi oleh objek

session. Objek session yang digunakan

saat transaksi dikendalikan oleh class proxy

yang dihasilkan melalui teknik Declarative

Transaction. Ketika lapisan aplikasi

memanggil Service untuk mengakses basis

data, method Service tidak mengakses

basis data secara langsung. Akan tetapi

Service memanggil moduleXXXService

pada file hibernate.ctx.xml untuk

membuat class proxy yang berisi fungsi-

fungsi transaksi (begin, commit, rollback).

Fungsi-fungsi transaksi tersebut dimasukan

ke dalam Session melalui method

getHibernateTemplate, sehingga tidak

perlu menuliskan proses transaksi secara

programatik mengendalikan Session,

karena transaksi dilakukan secara deklaratif

oleh class proxy melalui method

getHibernateTemplate.

5 Membuat Skema Basis Data.

Properti <prop key = "hibernate. hbm2ddl.auto"> ${hibernate.

hbm2ddl.auto} </prop> adalah property

untuk membuat skema basis data. Variabel

${hibernate.hbm2ddl.auto} merujuk

pada properti hibernate.hbm2ddl.auto

pada file jdbc.properties. nilai

variabelnya adalah create. Ada beberapa

pilihan yang bisa digunakan untuk properti

hbm2ddl.auto, yaitu create-drop

artinya Hibernate akan membuat semua

tabel pada saat inisialisasi

sessionFactory. Begitu

sessionFactory ditutup, semua tabel

akan dihapus. Pilihan yang ke dua adalah

create artinya pada saat

sessionFactory dijalankan akan

membuat semua tabel dan pada saat

sessionFactory ditutup tabel yang

dihasilkan tidak akan dihapus.

Selain properti hbm2ddl.auto, yang

digunakan pada proses pembuatan skema

basis data adalah properti

hibernate.show_sql. Properti

hiberntae.show_sql akan menampilkan

SQL yang digunakan saat query

menggunakan HQL. Skema basis data yang

dihasilkan digambarkan pada Lampiran 6.

6 Menyatukan Lapisan Persistensi

dengan Lapisan Aplikasi

Framework yang digunakan pada lapisan

aplikasi dan presentasi adalah Java Server

Faces (JSF). JSF adalah UI (User Interface)

framework untuk aplikasi Java berbasis web

dengan konsep MVC yang mendukung user

interface berbasis komponen. Setiap action

yang dilakukan memerlukan class controller

atau backing bean. Pada class controller

biasanya dilakukan proses pengaksesan

terhadap basis data.

Class controller yang akan mengakses

atau memanipulasi data memanggil method

Service sesuai data yang diperlukan.

Misalnya jika diperlukan data Item, maka

DAO yang berisi method untuk mengakses

data Item disimpan pada ItemDao,

kemudian ItemDao dimasukan ke dalam

InventoryService. Oleh karena itu,

untuk mengakses data Item dipanggil

InventoryService. Dan terakhir

mengatur konfigurasi controller untuk JSF

pada file faces-config.xml. method

Service yang digunakan oleh controller

14

dideklarasikan pada file konfigurasi faces-

config.xml.

Contoh class controller yang mengakses

data adalah seperti berikut:

1 public class InventoryController {

2 private InventoryService

3 inventoryService;

4 private Item item;

5 @PostConstruct

6 public void initBean(){

7 }

8 public String save(){

9 item.setStatus("active");

10 InventoryService.saveItem (item);

11 return "success";}

12 }

Method initBean pada baris lima dan

enam yang dianotasi oleh

@PostConstruct, artinya method ini

dipanggil setelah constructor

ListInvController dipanggil yang

bertujuan inisialisasi data pada halaman

tampilannya. Class Controller di atas

bertugas untuk menyimpan objek item ke

dalam basis data seperti dituliskan pada

baris sepuluh

Class Controller yang telah dibuat

dideklarasikan pada file konfigurasi faces-

config.xml seperti berikut:

1 <managed-bean>

2 <managed-bean-name>

3 InventoryController

4 </managed-bean-name>

5 <managed-bean-class>

6 ilkom.erp.web.controller.

7 inventory.InventoryController

8 </managed-bean-class>

9 <managed-bean-scope>

10 Request

11 </managed-bean-scope>

12 <managed-property>

13 <property-name

14 inventoryService

15 </property-name>

16 <value>

17 #{moduleInventoryService}

18 </value>

19 </managed-property>

20 </managed-bean>

Baris ke tiga merupakan penulisan

deklarasi nama controller yang akan

dipanggil pada lapisan presentasi. Nama

controller tersebut berisi class controller

yang didefinisikan pada baris ke enam dan

baris ke tujuh. Properti yang dipunyai

controller tersebut didefinisikan pada baris

ke 12 sampai baris ke 19.

Evaluasi

Proses pemetaan menggunakan ORM

dituliskan dengan kode sederhana, hal ini

sangat membantu pihak pengembang dalam

melakukan query data. ORM menghilangkan

kode-kode exception dan native query yang

terlihat berantakan dan tidak terstruktur.

ORM mengabstraksi penggunakan

Relational Data Base Management System

(RDBMS), sehingga mendukung jenis

RDBMS manapun. Query yang digunakan

tidak menurut pada satu jenis RDBMS,

melainkan menggunakan query language

yang disediakan oleh ORM.

Pemanfaatan konsep design pattern

menghasilkan kode program yang lebih rapi

dan terstruktur, serta memudahkan untuk

proses integrasi antara lapisan basis data dan

lapisan aplikasi. Dengan penerapan konsep

design pattern, kode program aplikasi dapat

dengan mudah dipelihara untuk

pengembangan aplikasi selanjutnya.

Perbedaan fungsi akses data tanpa

menggunakan ORM, teknik Inversion of

Controls, dan teknik Declarative

Transaction, akses data menggunakan ORM

tetapi tanpa penerapan teknik Inversion of

Controls dan teknik Declarative

Transaction, dan fungsi akses data

menggunakan ORM, Inversion of Controls,

dan teknik Declarative Transaction dapat


Kekurangan dari konsep ORM yang

diterapkan dalam pengembangan sistem

ERP yaitu apabila terjadi perubahan,

penambahan, dan pengurangan domain

model harus meliputi seluruh aspek dari

mulai pembuatan DTO, DAO, Service,

dan deklarasi pada file konfigurasi.

KESIMPULAN DAN SARAN

Kesimpulan

Pada penelitian ini, tidak semua aspek

ketidaksesuaian ditemukan. Aspek

ketidaksesuaian yang muncul pada

penelitian ini hanya meliputi empat aspek,

yaitu aspek granularity, identitas, navigasi

data, dan asosiasi antarentitas. Implementasi

konsep ORM terbukti dapat menghilangkan

ketidaksesuian yang muncul karena

perbedaan antara aplikasi yang dibangun

dengan pendekatan berorientasi objek dan

basis data relasional yang digunakan.

15

Penerapan ORM yang dilengkapi dengan

design pattern membuat sistem ERP

terstruktur dalam pengelolaan basis datanya.

ORM menghemat resource untuk koneksi

pada basis data serta proses konfigurasinya

mudah untuk dikelola, ORM tidak

bergantung pada jenis RDBMS apapun,

sehingga apabila terjadi perubahan atau

migrasi RDBMS tidak perlu mengubah SQL

menurut RDBMS yang digunakan.

Penerapan design pattern pada teknik

Declarative Transaction dan Inversion of

Controls dapat memudahkan proses

pengaksesan dan manipulasi pada lapisan

aplikasi (controller). Fungsi-fungsi

pengaksesan basis data dapat digunakan

berulang-ulang sehingga sistem ERP mudah

untuk dikembangkan.

Saran

Penerapan ORM lebih lanjut bisa

dilengkapi dengan melakukan proses

pengujian terhadap pengaksesan basis data

menggunakan DBUnit. Penelitian

selanjutnya bisa dilakukan dengan

mengukur waktu eksekusi antara

pengaksesan basis data menggunakan ORM

dan pengaksesan basis data tanpa

menggunakan ORM. Selain itu juga,

penelitian selanjutnya dapat dilakukan

dengan menganalisis penerapan ORM pada

framework yang berbeda (TopLink,

openJPA, atau iBatis) atau pada platform

yang berbeda (.Net).

DAFTAR PUSTAKA

Alur D, Crupi J, Malks D. 2003. Core

J2EE™ Patterns: Best Practices and

Design Strategies, Ed ke-2. United

States: Addison-Wesley.

Bauer C, King G. 2007. Java Persistence

with Hibernate. United States : Manning.

Connolly TM, Carolyn EB. 2002. Database

System: A Practical Approach To

Design, Implementation, and

Management. England: Addison-Wesley.

Ernita, H. 2008. Pengembangan Enterprise

Resource Planning Untuk Perusahaan

Ritel. Prosiding Paper Seminar Nasional

Informatika 2008 UPN Veteran

Yogyakarta. 24 Mei 2008. Buku 2:23-32.

Gamma et al. 1995. Design Patterns:

Elements of Reusable Object-Oriented

Software. United States: Addison-

Wesley.

Husted T. 2003. Struts in Action : Building

Web Application with the Leading Java

Framework. United States : Manning.

McGovern J. 2003. Java™ 2 Enterprise

Edition 1.4 Bible. Canada: Willey

Publishing.

Nugraha B. 2005. Object Relational

Mapping. [Skripsi]. Bogor: Departemen

Ilmu Komputer, Institut Pertanian Bogor.

Parr A. N. 2000. A Taxonomi of ERP

Implementation Approach. School of

Business System, Monash University.

Peak P, Heudecker N. 2006. Hibernate

Quickly. United States: Manning.

Rashid et. al. 2002. The Evolution of ERP

System: A Historical Perspective. USA:

IRM Press.

Thamura F. et al. 2007. Cara Cepat

Mengembangkan Solusi Java Enterprise

dengan Arsitektur MVC. Jakarta:

Bambumas.

Wahab H. 2007. Struts Framework dan JEE

Pattern Dalam Pengembangan Sistem

Informasi Akademik IPB. [Skripsi].

Bogor: Departemen Ilmu Komputer,

Institut Pertaniahn Bogor.

Walls C, Breidenbach R. 2005. Spring in

Action. United States: Manning.

LAMPIRAN

17

Lampiran 1 Daftar Tabel

1. Modul accountPayable

no Nama tabel keterangan

1. AP_INVOICE Tabel transaksi invoice account payable

2. AP_INVOICE_DETAIL Tabel transaksi invoice detail account payable

3. AP_PAYMENT Tabel transaksi payment account payable

4. AP_PAYMENT_DETAIL Tabel transaksi payment detail account payable

5. AP_MONTHEND Tabel transaksi month end process account payable

2. Modul accountPayment


1. AR_INVOICE Tabel transaksi invoice account receiveable

2. AR_INVOICE_DETAIL Tabel transaksi invoice detail account receiveable

3. AR_RECEIPT Tabel transaksi payment account receiveable

4. AR_RECIEPT_DETAIL Tabel transaksi payment detail account receiveable

5. AR_MONTHEND Tabel transaksi month end process account receiveable

3. Modul admin


1. AD_ACCOUNT_PERIODE Tabel master periode kode akun

2. AD_COMPANY Tabel master informasi perusahaan

3. AD_GROUP Tabel master grup (role) pegawai

4. AD_MODUL Tabel master modul untuk masing-masing role

5. AD_MODUL_PERIODE Tabel master periode modul

6. AD_PAGE Tabel master daftar halaman (screen page)

7 AD_UOM Tabel master unit of measurement (satuan pengukuran)

8. AD_UOM_CONVERTION Tabel master konversi unit pengukuran

9. AD_USER Tabel master daftar pengguna

10. AD_VEHICLE Tabel master daftar kendaraan

11. AD_GROUP_MODUL Tabel hasil asosiasi many-to-many group dan modul

4. Modul generalLedger


1. GL_JOURNAL Tabel transaksi pos jurnal

2. GL_JOURNAL_DETAIL Tabel transaksi pos jurnal detail

3. GL_MONTHEND Tabel transaksi month end process

4. GL_ACCOUNT Tabel master kode akun

5. Modul Inventory


1. IN_GOODS_RECEIVE Tabel transaksi goods receive

2. IN_GOODS_RECEIVE_DETAIL Tabel transaksi goods receive detail

3. IN_ITEM Tabel master manajemen inventory

4. IN_MONTHEND_ITEM Tabel transaksi month end process inventory

5. IN_PROD_BRAND Tabel master produc brand

6. IN_PROD_CATEGORY Tabel master product category

18

6. Modul Order


1. OR_CART Tabel transaksi add to cart

2. OR_CART_DETAIL Tabel transaksi cart detail

3. OR_DEBITUR Tabel master daftar debitur (costumer)

4. OR_DELIVERY Tabel transaksi pengantaran barang

5. OR_MONHTEND_TRX Tabel transaksi month end process

6. OR_PAYMENT_TYPE Tabel master tipe pembayaran

7. OR_SHIPPING_TYPE Tabel master tipe pengirirman barang

7. Modul Purchase


1. PU_DEMAND Tabel transaksi demand order (DO)

2. PU_DEMAND_DETAIL Tabel transaksi demand order detail

3. PU_MONTHEND_TRX Tabel transaksi month end process

4. PU_ORDER Tabel transaksi purchase order (PO)

5. PU_ORDER-DETAIL Tabel transaksi purcahse order detail

6. PU_REQUISITION Tabel transaksi purchase requisition

7. PU_REQUISITION_DETAIL Tabel transaksi purchase requisition detail

8. PU_SUPPLIER Tabel master daftar supplier

9. PU_RFQ Tabel transaksi request for quotation

10. PU_RFQ_DETAIL Tabel transaksi request for quotation detail

11. PU_RFQ_PRICE Tabel transaksi harga yang diinput supplier

12. PU_RFQ_SUPPLIER Tabel asosiasi many-to-many RFQ dan supplier

13. PU_SUPPLIER_RFQ Tabel asosiasi many-to-many supplier dan RFQ

19

Package purchase

-id : Long

-code : String

-refNO : String

-refDate : Date

-amount : Double

-accMonth : Integer

-accYear : Integer

-status : String

-createDate : Date

-updateDate

-supplier : Supplier

-demand : Demand

Invoice

Modul admin

-id : Long

-name : String

-status : String

-expiredDate : Date

-createDate : Date

-updateDate : Date

-groups : Group

Modul

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM

Package inventory

-id : Long

-desc : String

-reOrderLevel : Integer

-bin : String

-qtyOnHand : Integer

-qtyOnHold : Integer

-qtyOnOrder : Integer

-qtyReORder : Integer

-initCost : Double

-lowCost : Double

-highCost : Double

-avrgCost : Double

-diffAvrgCost : Double

-closingBal : Double

-closingAvrgBal : Double

-closingDiffAvrgCost : Double

-status : String

-lastOrderDate : Date

-lastIssueDate : Date

-createDate : Date

-updateDate : Date

-lastCostFinal : Double

-latestCostInitial : Double

-latestCostSecond : Double

-sellFixPrice : Double

-sellLatestCost : Double

-sellAvrgCost : Double

-attach : Byte

-prodCat : ProdCat

-prodBrand : ProdBrand

-glAcc : Account

-uom : UOM

Item

Package

generalLedger

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

-id : Long

-name : String

-contactPerson : String

-creditTerm : String

-creditLimit : Double

-bankAccName : String

-bankAccNo : String

-status : String

-createDate : Date

-updateDate : Date

-address : Address

-glAcc

Supplier

-id : Long

-code : String

-amount : Double

-deliveryAddress : String

-deliveryDate : Date

-transDate : Date

-status : String

-accMonth : Integer

-accYear : Integer

-status : String

-order : Order


Demand

-demand

1

-invoice

1

-supplier

1

-invoice

*

-id : Long

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-invoice : Invoice

-acc : Account

-monthend

InvoiceDetail

-invoiceDetail

1

-invoice*

-invoiceDetail1

-item

1

-acc

1

-invoiceDetail 1-uom 1

-invoiceDetail

1 -id : Long

-idDoc : String

-idDocDetail : String

-docType : String

-docDate : Date

-accYear : Integer

-accMonth : Integer

-desc : String

-quantity : Integer

-price : Double

-amount : Double

-status : String

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-acc : Account

-modul : Modul

MonthEnd

-monthEnd

1

-modul

1

-monthEnd

1

-acc

1

-item

1

-monthEnd

1

-monthEnd

1

-uom1

-id : Long

-code : String

-amount : Double

-accYear : Integer

-accMonth : Integer

-status : String

-createDate : Date

-updateDate : Date


Payment

-id : Long

-amount : Double

-status : String

-createDae : Date

-updateDate : Date

-payment : Payment

-invoice : Invoice

-acc : Account

-monthEnd : MonthEnd

PaymentDetail

-payment

1-supplier *

-paymentDetail1

-payment*

-paymentDetail1

-acc

1

-monthEnd 1

-paymentDetail

*

-paymentDetail1

-invoice1

Lampiran 2 Class Diagram Data Transfer Object

a. Modul AccountPayable

20

Package order

Modul admin

-id : Long

-name : String

-status : String

-expiredDate : Date

-createDate : Date

-updateDate : Date

-groups : Group

Modul

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM Package inventory

-id : Long

-desc : String


-bin : String





-initCost : Double

-lowCost : Double

-highCost : Double

-avrgCost : Double





-status : String



-createDate : Date

-updateDate : Date







-attach : Byte

-prodCat : ProdCat


-glAcc : Account

-uom : UOM

ItemPackage

generalLedger

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

-id : Long

-name : String


-address : String

-town : String

-state : String

-postCode : String

-telpNo : String

-faxNO : String

-email : String



-status : String

-password : String

Debitur

-id : Long

-cartCode : String

-status : String

-refId : String

-amount : Double

-transDate : Date

-accYear : Integer

-accMonth : Integer

-status : String

-createDate : Date

-updateDate : Date

-shippingType : ShippingType

-paymentType : PaymentType

-debitur : Debitur

Cart

-id : Long

-code : String

-amount : Double

-accMonth : Integer

-accYear : Integer

-status

-createDate : Date

-updateDate : Date

-debitur : Debitur

-cart : Cart

Invoice

-cart

1

-invoice

1

-debitur1

-invoice*

-id : Long

-desc : String

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-invoice : Invoice

-item : Item

-uom : UOM

-acc : Account

InvoiceDetail

-invoice*

-invoiceDetail1

-acc

1

-invoiceDetail

1

-uom 1

-invoiceDetail

1

-item

1

-invoiceDetail

1

-id : Long

-idDoc : String

-idDocDetail : String

-docType : String

-docDate : Date

-accMonth : Integer

-accYear : Integer

-desc : String

-quantity : Integer

-price : Double

-amount : Double

-status : String

-modul : Modul

-item : Item

-uom : UOM

-acc : Account

MonthEnd

-uom

1

-monthEnd

1

-monthEnd

1

-item

1

-acc

1

-monthEnd 1

-monthEnd 1

-modul 1

-id : Long

-code

-amount : Double

-accMonth : Integer

-accYear : Integer

-status : String

-createDate : Date

-updateDate : Date

-debitur : Debitur

Receipt

-debitur 1

-receipt

*

-id : Long

-amount : Double

-status : String

-createDate : Date

-updateDate : Date

-receipt : Receipt

-invoice : Invoice

-acc : Account

ReceiptDetail

-receiptDetail1

-acc1

-receiptDetail1

-invoice1

-receiptDetail

1

-receipt

*

Lanjutan Lampiran 2 Class Diagram

b. Modul AccountReceivable

21

Package inventory

Package admin

-id : Long

-code : String

-docRefNo : String

-docRefDate : String

-docAmount : Double

-total : Double

-accMonth : Integer

-accYear : Integer

-status : String

Journal

-id : Long

-amount : Double

-desc : String

-status : String

-createDate : Date

-updateDate : Date

-account

-journal : Journal

JournalDetail-id : Long

-idDoc : Long

-idDocDetail : Long

-docType : String

-docDate : Date

-accMonth : Integer

-accYear : Integer

-desc : String

-amount : Double

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-modul : Modul

-item : Item

-accCode : Account

-uom : UOM

MonthEnd

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

-acc

1

-monthEnd

*

-journalDetail

1 -journal

*

-id : Long

-name : String

-status : String

-expiredDate : Date

-createDate : Date

-updateDate : Date

-groups : Group

Modul

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM

-uom

1 -monthEnd

1

-modul1

-monthEnd

1

-id : Long

-desc : String


-bin : String





-initCost : Double

-lowCost : Double

-highCost : Double

-avrgCost : Double





-status : String



-createDate : Date

-updateDate : Date







-attach : Byte

-prodCat : ProdCat


-glAcc : Account

-uom : UOM

Item

-monthEnd

1

-item

1


c. Modul GeneralLedger

22

Package

generalLedger

-id : Long

-accYear : Integer

-maxPeriode : Integer

-status : String

-createDate : Date

-updateDate : Date

AccPeriode

-id : Long

-companyName : String

-address : String

-city : String

-state : String

-postCode : String

-telpNo : String

-faxNo : String

-status : String

-createDate : Date

-updateDate : Date

Company

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

-moduls : Modul

Group

-id : Long

-name : String

-status : String

-expiredDate : Date

-createDate : Date

-updateDate : Date

-groups : Group

Modul

-id : Long

-inAccMonth : Integer

-inAccYear : Integer

-puAccMonth : Integer

-puAccYear : Integer

-orAccMonth : Integer

-orAccYear : Integer

-arAccMonth : Integer

-arAccYear : Integer

-apAccMonth : Integer

-apAccYear : Integer

-glAccMonth : Integer

-glAccYear : Integer

-createDate : Date

-updateDate : Date

ModulPeriode

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM

-id : Long

-rate : Integer

-status : String

-createDate : Date

-updateDate : Date

-uomTo : UOM

-uomFrom : UOM

UOMConvertion

-id : Long

-name : String

-password : String

-email : String

-employeId : String

-role : String

-status : String

-createDate : Date

-updateDate : Date

-groups : Group

User

-id : Long

-desc : String

-type : String

-load : Integer

-driver : String

-model : String

-capacity : Integer

-status : String

-createDate : Date

-updateDate : Date

-uom : UOM

-acc : Account

Vehicle

-id : Long

-name : String

-url : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

-modul : Modul

Page

-user

*

-groups

1

-uomConverttion 1

-uom *-moduls*

-groups*

-modul

1

-page

*

-uom *

-vehicle 1

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

-vehicle

1

-acc

*


d. Modul Admin

23

Package

generalLedger

Package admin

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

ProdBrand

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

ProdCat

-id : Long

-desc : String


-bin : String





-initCost : Double

-lowCost : Double

-highCost : Double

-avrgCost : Double





-status : String



-createDate : Date

-updateDate : Date







-attach : Byte

-prodCat : ProdCat


-glAcc : Account

-uom : UOM

Item

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

-item

1

-prodBrand

*

-item

1

-prodCat

*

-uom

1

-item

1

-account

1

-item

1

-id : Long

-transDate : Date

-status : String

-createDate : Date

-updateDate : Date


-supplier

-demand

GoodsReceive

-id : Long

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-goodsReceive : GoodsReceive

GoodsReceiveDetail

-detail1

-goodReceive

*

-uom 1

-goodReceiveDetail 1 -goodsReceiveDetail1

-uom

1

-id : Long

-accMonth : Integer

-accYear : Integer

-quantity : Integer

-avrgCost : Double

-amount : Double

-status : String

-createDate : Date

-updateDate : Date

-item : Item

MonthEndItem

-monthEnd

1

-item

1


e. Modul Inventory

24

-id : Long

-name : String


-address : String

-town : String

-state : String

-postCode : String

-telpNo : String

-faxNO : String

-email : String



-status : String

-password : String

Debitur -id : Long

-cartCode : String

-status : String

-refId : String

-amount : Double

-transDate : Date

-accYear : Integer

-accMonth : Integer

-status : String

-createDate : Date

-updateDate : Date

-shippingType : ShippingType

-paymentType : PaymentType

-debitur : Debitur

Cart

-id : Long

-price : Double

-quantity : Integer

-status : String

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-acc : Account

-cart : Cart

CartDetail

Package

generalLedger

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

Package inventory

-id : Long

-desc : String


-bin : String





-initCost : Double

-lowCost : Double

-highCost : Double

-avrgCost : Double





-status : String



-createDate : Date

-updateDate : Date







-attach : Byte

-prodCat : ProdCat


-glAcc : Account

-uom : UOM

Item

Modul admin

-id : Long

-name : String

-status : String

-expiredDate : Date

-createDate : Date

-updateDate : Date

-groups : Group

Modul

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM

-id : Long


-driver : String

-load : Integer

-createDate : Date

-updateDate : Date

-vehicle : Vehicle

-debitur : Debitur

-uom : UOM

Delivery

-id : Long

-desc : String

-type : String

-load : Integer

-driver : String

-model : String

-capacity : Integer

-status : String

-createDate : Date

-updateDate : Date

-uom : UOM

-acc : Account

Vehicle

-id : Long

-desc : String

-createDate : Date

-updateDate : Date

PaymentType

-id : Long

-idDoc : Long

-idDocDetail : Long

-docType : String

-docDate : Date

-accMonth : Integer

-accYear : Integer

-desc : String

-amount : Double

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-modul : Modul

-item : Item

-accCode : Account

-uom : UOM

MonthEnd-id : Long

-desc : String

-createDate : Date

-updateDate : Date

ShippingType

-cart

1

-shipping

1

-payment1

-cart*

-cart

1

-debitur

*

-cart *

-cartDetail

1

-uom

1

-cartDeail

1

-item

1-cartDetail1

-acc

1

-cartDetail

1

-debitur 1

-delivery

1

-acc1

-vehicle

1

-uom

1

-monthend

1

-acc

1

-monthend

1

-item1

-monthend

1

-modul1

-monthend

1


f. Modul Order

25

Modul admin

-id : Long

-name : String




-bankAccName : String

-bankAccNo : String

-status : String

-createDate : Date

-updateDate : Date

-address : Address

-glAcc

Supplier

-address : String

-town : String

-state : String

-postCode : String

-telpNo : String

-faxNo : String

-email : String

Address-address1

-supplier

1

-id : Long

-code : String

-transDate : Date

-status : String

-createDate : Date

-updateDate : Date

-accYear : Integer

-accMonth : Integer

Requisition

Package inventory

-id : Long

-desc : String


-bin : String





-initCost : Double

-lowCost : Double

-highCost : Double

-avrgCost : Double





-status : String



-createDate : Date

-updateDate : Date







-attach : Byte

-prodCat : ProdCat


-glAcc : Account

-uom : UOM

Item

-id : Long

-quantity : Integer

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-requisition : Requisition

RequisitionDetail

Package

generalLedger

-id : Long

-code : String

-desc : String

-status : String

-createDate : Date

-updateDate : Date

Account

-id : Long

-name : String

-status : String

-expiredDate : Date

-createDate : Date

-updateDate : Date

-groups : Group

Modul

-id : Long

-desc : String

-status : String

-createDate : Date

-updateDate : Date

UOM

-reqDetail1

-requisition*

-item

1-reqDEtail

1

-uom

1

-eqDetail

1

-id : Long

-code : String

-amount : Double

-status : String


-supplierPrice : Supplier

-selectedSupplier : Supplier

-requisition : Requisition

-deliveryDate : String

-accMonth : Integer

-accYear : Integer

-createDate : Date

-updateDate : Date

RFQ

-id : Long

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-rfq : RFQ

RFQDetail

-rfqDetail*

-rfq1

-item

1

-rfqDetail

1

-uom1

-reqDetail

1

-id : Long

-price : Double

-deliveryDate : String

-rfqDetail : RFQDetail


Price

-price

1

-rfqDetail

*

-id : Long

-code : String

-amount : Double



-transDate : Date

-status : String

-accYear : Integer

-accMonth : Integer

-createDate : Date

-updateDate : Date

-rfq : RFQ


Order

-rfq 1-order*

-supplier1

-order*

-id : Long

-code : String

-amount : Double



-transDate : Date

-status : String

-accMonth : Integer

-accYear : Integer

-status : String

-order : Order


Demand

-supplier

1

-demand

*

-order 1

-demand

1

-id : Long

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-item : Item

-uom : UOM

DemandDetail

-demandDetail1

-demand*

-id : Long

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-item : Item

-uom : UOM

-order : Order

OrderDetail

-order*

-orderDetail 1

-item 1

-orderDetail*

-uom1

-orderDetail*

-item

1

-demandDetail 1

-uom

1

-demandDetail

*

-id : Long

-idDoc : Long

-idDocDetail : Long

-docType : String

-docDate : Date

-accMonth : Integer

-accYear : Integer

-desc : String

-amount : Double

-quantity : Integer

-price : Double

-status : String

-createDate : Date

-updateDate : Date

-modul : Modul

-item : Item

-accCode : Account

-uom : UOM

MonthEnd

-modul

1

-monthEnd

1

-uom

1

-monthEnd 1

-item 1

-monthEnd 1

-account

1

-monthEnd

1


g. Modul Purchase

26

AD_USER

PK UserID

FK1 GroupCode

AD_ACC_PERIODE

PK accPeriodCode

AD_COMPANY

PK CompCode

AD_GROUP

PK GroupCode

AD_MODULE_GROUP

FK1 GroupCode

FK2 ModuleCode

AD_MODULE

PK ModuleCode

AD_MODUL_PERIOD

PK modulPeriodCode

AD_PAGE

PK PageCode

FK1 ModuleCode

AD_UOM

PK UOMCode

AD_UOMCONVERTION

PK UOMFrom

PK UOMTo

FK1 UOMCode

AD_VEHICLE

PK VehicleCode

FK1 UOMCode

FK2 AccCode

Modul

generalLedger

GL_ACCOUNT2

PK AccCode

1…*

1

1…*

1…*

1

1

1…*

1

1

1

1

1

1

1

GL_JOURNAL

PK JournalCode

GL_JOURNAL_DETAIL

PK JournalDetailCode

FK1 JournalCode

FK2 AccCode

GL_MONTHEND

PK monthEndCode

FK1 ModuleCode

FK2 UOMCode

FK3 AccCode

FK4 ItemCode

GL_ACCOUNT

PK AccCodeModul admin

AD_MODULE

PK ModuleCode

AD_UOM

PK UOMCode

Modul inventory

IN_ITEM

PK ItemCode

ProdCatCode

ProdBrandCode

1…*

1

1

1

1

1

1

11

1

1

1

Lampiran 3 ER Diagram

a. Modul admin

b. Modul general Ledger

27

Modul purchase

Modul adminIN_PROD_BRAND

PK ProdBrandCode

IN_PROD_CAT

PK ProdCatCode

IN_ITEM

PK ItemCode

FK1 ProdBrandCode

FK2 ProdCatCode

FK3 AccCode

FK4 UOMCode

IN_GOODS_RECEIVE

PK GoodReceiveCode

FK1 DemandCode

FK2 SupplierCode

IN_GOODS_RECEIVE_DETAIL

PK GdRcvDetailCode

FK1 GoodReceiveCode

FK2 ItemCode

FK3 UOMCode

AD_UOM

PK UOMCode

PU_DEMAND

PK DemandCode

OrderCode

SupplierCode

PU_SUPPLIER

PK SupplierCode

AccCode

IN_MONTHEND_ITEM

PK monthItemEndCode

Modul

generalLedger

GL_ACCOUNT3

PK AccCode

1

1..*

1

1..*

1

1

1

1

1

1

1

1

1

1

1

1 1

1..*

1

Modul admin

OR_PAYMENT_TYPE

PK paymentTypeCode

OR_MONTHENDTRX

PK monthEndCode

FK1 ModuleCode

FK2 AccCode

FK3 UOMCode

FK4 ItemCode

OR_CART

PK CartCode

FK1 paymentTypeCode

FK2 shippingTypeCode

FK3 DebiturCode

OR_CART_DETAIL

PK CartDetailCode

FK1 CartCode

FK2 ItemCode

FK3 UOMCode

FK4 AccCode

OR_DELIVERY

PK DeliveryCode

FK1 VehicleCode

FK2 UOMCode

FK3 DebiturCode

OR_SHIPPING_TYPE

PK shippingTypeCode

OR_DEBITUR

PK DebiturCode

FK1 AccCode

Modul

generalLedger

GL_ACCOUNT

PK AccCode

Modul inventory

IN_ITEM

PK ItemCode

ProdCatCode

ProdBrandCode

AD_UOM

PK UOMCode

AD_MODULE

PK ModuleCode

AD_VEHICLE

PK VehicleCode

1..*

1

1

1

1

1

1..*

1

1

1

1

1

11

1

1

1

1

1

1

11111

1

1

1

1

1

1

1

1

c. Modul inventory

d. Modul order

28

PU_SUPPLIER

PK SupplierCode

FK1 AccCode

PU_REQUISITION

PK requisitionCode

PU_REQUISITION_DETAIL

PK reqDetailCode

FK1 requisitionCode

FK2 UOMCode

FK3 ItemCode

PU_RFQ

PK RFQCode

FK1 SupplierCode

FK2 requisitionCode

PU_RFQ_PRICE

PK priceCode

FK1 RFQCode

FK2 SupplierCode

PU_RFQ_DETAIL

PK RFQDetailCode

FK1 ItemCode

FK2 UOMCode

FK3 RFQCode

PU_RFQ_SUPPLIER

FK1 RFQCode

FK2 SupplierCode

PU_SUPPLIER_RFQ

FK1 RFQCode

FK2 SupplierCode

PU_MONTHENDTRX

PK monthEndCode

FK1 ItemCode

FK2 UOMCode

FK3 ModuleCode

PU_ORDER

PK OrderCode

FK1 RFQCode

FK2 SupplierCode

PU_ORDER_DETAIL

PK OrderDetailCode

FK1 OrderCode

FK2 ItemCode

FK3 UOMCode

PU_DEMAND

PK DemandCode

FK1 OrderCode

FK2 SupplierCode

PU_DEMAND_DETAIL

PK DemmandDetailCOde

FK1 UOMCode

FK2 ItemCode

FK3 DemandCode

Modul admin

AD_MODULE

PK ModuleCode

Modul

inventory

IN_ITEM

PK ItemCode

ProdCatCode

ProdBrandCode

AD_UOM

PK UOMCode

Modul

generalLedger

GL_ACCOUNT

PK AccCode

1..*

1

1

1…

*

1…

*

1…

*

1

1

1

1

1

1

1

1..*

1

1

1

1

1

1..*

1

1

1

1..*

1

1

1..*

1

1..*

1

1

1

1

1

1

1

1…

*

1

1..*

1

1

1

1

1…

*

1

1

1

1

1

1

1

1

e. Modul purchase

29

Modul order

AR_RECEIPT

PK ARRcptCode

FK1 DebiturCode

AR_RCPT_DETAIL

PK ARRcptDetailCode

FK1 ARRcptCode

FK2 ARInvoiceCode

FK3 AccCode

AR_INVOICE

PK ARInvoiceCode

FK1 DebiturCode

FK2 CartCode

AR_INV_DETAIL

PK ARInvDetailCode

FK1 ARInvoiceCode

FK2 ItemCode

FK3 UOMCode

FK4 AccCode

AR_MONTHEND

PK monthEndCode

FK1 ModuleCode

FK2 AccCode

FK3 ItemCode

FK4 UOMCode

Modul

generalLedgerGL_ACCOUNT

PK AccCode

Modul admin

AD_MODULE

PK ModuleCode

AD_UOM

PK UOMCode

Modul inventory

IN_ITEM

PK ItemCode

ProdCatCode

ProdBrandCode

OR_CART

PK CartCode

paymentTypeCode

shippingTypeCode

DebiturCode

OR_DEBITUR

PK DebiturCode

1..*

1

1..*

1

1..*

1

1 1

11

1..*

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

f. Modul account receivable

30

AP_INVOICE

PK APInvoiceCode

FK1 DemandCode

FK2 SupplierCode

AP_INV_DETAIL

PK APInvDetailCode

FK1 APInvoiceCode

FK2 ItemCode

FK3 AccCode

FK4 UOMCode

FK5 monthEndCode

AP_MONTHEND

PK monthEndCode

FK1 AccCode

FK2 ItemCode

FK3 UOMCode

FK4 ModuleCode

AP_PAYMENT

PK APPaymentCode

FK1 SupplierCode

AP_PAYMENT_DETAIL

PK APPayDetailCode

FK1 APPaymentCode

FK2 APInvoiceCode

FK3 monthEndCode

FK4 AccCode

Modul purchase

PU_DEMAND

PK DemandCode

OrderCode

SupplierCode

PU_SUPPLIER

PK SupplierCode

AccCode

Modul admin

AD_MODULE

PK ModuleCode

AD_UOM

PK UOMCode

Modul inventory

IN_ITEM

PK ItemCode

ProdCatCode

ProdBrandCode

Modul

generalLedger

GL_ACCOUNT

PK AccCode

1

1..*

1

1

1

1

1

1

1

1

1

1

1..*1

1

1 1

1

1

1

1

1

1

1

1..*

11

1 1

1

1

1

g. Modul account payable

Lampiran 4 Kamus data

a. Modul admin

Nama tabel: AD_USER

NO COLUMN NAME DATA TYPE MANDATORY DESCRIPTION

1 id BIGINT(20) yes id untuk tabel user

2 user_name VARCHAR(255) yes, unique nama user

3 user_email VARCHAR(255) yes, unique alamat email

4 user_pswd VARCHAR(255) yes password user

5 employee_id VARCHAR(255) id staff/pegewai

6 create_date DATETIME tanggal tabel dibuat

7 update_date DATETIME tanggal tabel terakhir diupdate

31

Nama tabel : AD_COMPANY

Nama tabel : AD_GROUP


1 id BIGINT(20) yes id untuk tabel group

2 group_desc VARCHAR(255) yes deskripsi untuk setiap group

3 group_status VARCHAR(255) yes status tabel ("active", "inactive")



Nama tabel : AD_VEHICLE


1 id BIGINT(20) yes id untuk tabel vehicle

2 vehicle_desc VARCHAR(255) yes deskripsi dari kendaraan

3 vehicle_status VARCHAR(255) yes status tabel ("active", "inactive")



6 vehicle_type_code VARCHAR(255) tipe kendaraan

7 capacity INTEGER yes kapasitas muatan kendaraan

8 model VARCHAR(255) model kendaraan

9 id_ad_uom BIGINT(20) yes satuan unit yang dipakai

10 id_gl_acc BIGINT(20) yes kode akun untuk setiap kendaraan


1 id BIGINT(20) yes id untuk tabel company

2 company_name VARCHAR(255) yes nama perusahaan

3 address VARCHAR(255) yes alamat perusahaan

4 post_code VARCHAR(255) kode pos

5 state VARCHAR(255) provinsi

6 city VARCHAR(255) kota

7 telp_no VARCHAR(255) nomor telpon

8 fax_no VARCHAR(255) nomor faximile

9 company_status VARCHAR(255) yes status tabel ("active", "inactive")



32

Nama tabel : AD_MODUL


1 id BIGINT(20) yes id untuk tabel modul

2 modul_name VARCHAR(255) yes deskripsi untuk setiap modul

3 modul_status VARCHAR(255) yes status tabel ("active", inactive)



6 expire_date DATETIME tanggal batas update modul

Nama tabel : AD_UOM


1 id BIGINT(20) yes id untuk tabel UOM

2 uom_desc VARCHAR(255) yes deskripsi dari setiap UOM

3 uom_status VARCHAR(255) yes status tabel ("active", "inactive")

5 create_date DATETIME tanggal tabel terakhir diupdate

6 update_date DATETIME tanggal batas update modul

Nama tabel : AD_UOMCONVERTION


1 id BIGINT(20) yes id untuk tabel UOMCONVERTER

2 id_uom_from BIGINT(20) yes satuan awal

3 id_uom_to BIGINT(20) yes satuan hasil

4 rate INTEGER yes perhitungan konversi

5 status VARCHAR(255) yes status tabel



Nama Tabel : GROUP_MODULE


1 id_ad_group BIGINT(20) yes FK dari tabel AD_GROUP

2 id_ad_modul BIGINT(20) yes FK dari tabel AD_MODULE

Nama tabel : AD_ACC_PERIODE


1 id BIGINT(20) yes id untuk tabel ad_acc_periode

2 max_periode BIGINT{20) yes max periode kode akun




33

Nama tabel : AD_PAGE


1 id BIGINT(20) yes id untuk tabel ad_page

2 name VARCHAR(255) yes nama page

3 desc VARCHAR(255) yes deskripsi

4 url VARCHAR(255) yes alamat url nya

5 id_ad_modul BIGINT(20) yes FK dari ad_modul

6 status VARCHAR(255) yes status tabel ("active", "inactive")



Nama tabel : AD_MODULE_PERIODE


1 id BIGINT(20) yes id untuk modul peroide (month end process)

2 in_acc_month INTEGER yes tutup buku inventory tiap bulan

3 in_acc_year INTEGER yes tutup buku inventory tiap tahun

4 pu_acc_month INTEGER yes tutup buku pembelian tiap bulan

5 pu_acc_year INTEGER yes tutup buku pembelian tiap tahun

6 or_acc_month INTEGER yes tutup buku penjualan tiap bulan

7 or_acc_year INTEGER yes tutup buku penjualan tiap tahun

8 ar_acc_month INTEGER yes tutup buku account receivable tiap bulan

9 ar_acc_year INTEGER yes tutup buku account receivable tiap tahun

10 ap_acc_month INTEGER yes tutup buku account payable tiap bulan

11 ap_acc_year INTEGER yes tutup buku account payable tiap tahun

12 gl_acc_month INTEGER yes tutup buku general ledger tiap bulan

13 gl_acc_year INTEGER yes tutup buku general ledger tiap tahun

b. Modul General Ledger

Nama tabel: GL_ACCOUNT


1 id BIGINT(20) yes id dari tabel GL_ACC

2 acc_desc VARCHAR(255) yes deskripsi dari kode akun

3 acc_status VARCHAR(255) yes status ("active", "inactive")



Nama tabel : GL_JOURNAL


1 id BIGINT(20) yes id untuk tabel GL_JOURNAL

2 journal_code VARCHAR(255) yes code tiap jurnal

34


3 journal_desc VARCHAR(255) yes deskripsi dari setiap kode jurnal

4 doc_ref_no VARCHAR(255) no dokumen referensi

5 doc_ref_date DATETIME tanggal dokumen referensi

6 doc_amount DOUBLE total amount yang ada pada dokumen

7 total DOUBLE yes total amount yang dimasukan ke journal

8 acc_month INTEGER yes tutup buku jurnal setiap bulan

9 acc_year INTEGER yes tutup buku jurnal setiap tahun

10 status VARCHAR(255) status tabel ("active", "inactive")



Nama tabel : GL_JOURNAL_DETAIL


1 id BIGINT(20) yes id untuk jornal detail

2 id_journal BIGINT(20) yes FK dari tabel GL_journal

3 amount DOUBLE yes total amount

4 id_gl_account BIGINT(20) yes FK dari tabel GL_acoount

5 line_desc VARCHAR(255)

6 status VARCHAR(255) yes status tabel ("active", "inactive")



Nama tabel : GL_JOURNAL_MONTHEND


1 id BIGINT(20) yes id untuk tabel GL_month_end

2 id_doc VARCHAR(255) yes id setiap dokumen yang masuk

3 doc_type VARCHAR(255) tipe dari setiap dokumen

4 doc_date DATETIME yes tanggal dokumen

5 acc_month INTEGER yes tutup buku proses month end setiap bulan

6 acc_year INTEGER yes tutup buku proses month end setiap year

7 month_end_desc VARCHAR(255) deskripsi dari monthend

8 quantity INTEGER yes banyaknya barang yang direkap

9 price DOUBLE yes harga tiap item


11 id_ad_modul BIGINT(20) yes FK dari tabel ad_modul

12 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc untuk kode akun

13 id_in_item BIGINT(20) yes FK darI tabel in_item untuk item

14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom untuk satuan tiap unit



35

c. Modul Purhcase

Nama tabel : PU_SUPPLIER

Nama tabel : PU_REQUISITION


1 id BIGINT(20) yes id tabel pu_requisition

2 PR_code VARCHAR(255) yes kode setiap transaksi RFQ

3 transaction_code DATETIME yes tanggal transaksi RFQ

4 status VARCHAR(255) yes status transaksi ("draft", "sent")



7 acc_year INTEGER tutup buku transaksi PR setiap bulan

8 acc_month INTEGER tutup buku transaksi PR setiap year

Nama tabel : PU_REQUISITION_DETAIL


1 id BIGINT(20) yes id tabel pu_requisition detail

2 id_in_item BIGINT(20) yes item yang masukan

3 quantity INTEGER yes banyaknya item

4 id_ad_uom BIGINT(20) yes satuan unit


1 Id BIGINT(20) yes id untuk tabel PU_SUPPLIER

2 sup_name VARCHAR(255) yes nama supplier

3 cont_person VARCHAR(255) yes kontak yang bisa dihubungi

4 address_street VARCHAR(255) jalan

5 address_town VARCHAR(255) kota

6 address_state VARCHAR(255) provinsi

7 address_post_code VARCHAR(255) kode pos

8 telp_no VARCHAR(255) nomor telpon

9 fax_no VARCHAR(255) nomor faximile

10 mobile_no VARCHAR(255) nomor handphone

11 email VARCHAR(255) yes alamat email

12 credit_term VARCHAR(255)

setalah barang diterima atau setelah tagihan

diterima

13 credit_limit DOUBLE batas maksimal kredit

14 bank_acc_name VARCHAR(255) yes nama bank

15 bank_acc_no VARCHAR(255) yes no rekening bank

16 sup_status VARCHAR(255) yes status ("active", "inactive")



19 id_ad_user BIGINT(20) yes fk dari tabel user

20 id_gl_account BIGINT(20) yes fk dari tabel general ledger

36


5 id_pu_requisition BIGINT(20) yes FK dari tabel pu_requisition




Nama tabel : PU_RFQ



2 RFQ_code VARCHAR(255) yes kode setiap transaksi PR

3 transaction_code DATETIME yes tanggal transaksi PR

4 amount DOUBLE yes total transaksi

5 id_pu_supplier BIGINT(20) yes daftar supplier yang dikirim RFQ

6 delivery_date DATETIME yes tanggal pengiriman barang

7 id_pu_requisition BIGINT(20) yes FK dari tabel pu_requisition




11 acc_year INTEGER tutup buku transaksi RFQ setiap bulan

12 acc_month INTEGER tutup buku transaksi RFQ setiap tahun

Nama tabel : PU_RFQ_DETAIL


1 id BIGINT(20) yes id tabel pu_rfq_detail



4 price DOUBLE yes harga per item


6 id_pu_rfq BIGINT(20) yes FK dari tabel pu_rfq




Nama tabel : PU_SUPPLIER_SENT_RFQ


1 rfq_id BIGINT(20) yes FK dari tabel pu_rfq

2 supplier_id BIGINT(20) yes FK dari tabel pu_supplier

37

Nama tabel : PU_SUPPLIER_SEND_PRICE


1 rfq_id BIGINT(20) yes FK dari tabel pu_rfq

2 supplier_id BIGINT(20) yes FK dari tabel pu_supplier

Nama tabel : PU_RFQ_PRICE


1 id BIGINT(20) yes id untuk tabel pu_rfq_price

2 price DOUBLE yes harga penawaran dari tiap-tiap supplier

3 delivery_date DATETIME tanggal pengiriman barang

4 id_pu_supplier BIGINT(20) yes FK dari tabel pu_supplier

Nama tabel : PU_ORDER


1 id BIGINT(20) yes id untuk tabel pu_rfq_price

2 price DOUBLE yes harga penawaran dari tiap-tiap supplier

3 delivery_date DATETIME tanggal pengiriman barang


Nama tabel : PU_ORDER_DETAIL


1 id BIGINT(20) yes id tabel pu_order_detail





6 id_pu_PO BIGINT(20) yes FK dari tabel pu_order




Nama tabel : PU_DEMAND



2 DO_code VARCHAR(255) yes kode setiap transaksi DO

3 transaction_code DATETIME yes tanggal transaksi DO

4 amount DOUBLE yes total transaksi


6 delivery_address VARCHAR(255) yes alamat pengiriman barang


8 id_pu_order BIGINT(20) yes FK dari tabel pu_order

38





12 acc_year INTEGER tutup buku transaksi DO setiap bulan

13 acc_month INTEGER tutup buku transaksi DO setiap year

Nama tabel : PU_DEMAND_DETAIL


1 id BIGINT(20) yes id tabel pu_demand_detail





6 id_pu_DO BIGINT(20) yes FK dari tabel pu_demand




Nama tabel : PU_MONTHEND_TRX


1 id BIGINT(20) yes id untuk tabel PU_month_end




5 acc_month INTEGER yes tutup buku proses monthend setiap bulan

6 acc_year INTEGER yes tutup buku proses monthend setiap tahun








14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom satuan tiap unit



39

d. Modul Inventory

Nama tabel : IN_ITEM


1 id BIGINT(20) YES

id inventory yang terdaftar pada tabel

in_item

2 item_desc VARCHAR(255) yes

deskripsi dari item yang terdaftar

pada tabel in_item

3 bin VARCHAR(255) lokasi penempatan di gudang

4 qty_on_hand INTEGER Yes

jumlah stok barang yang ada di

gudang dan tidak sedang dipesan

5 qty_on_order INTEGER

jumlah stok barang yang sudah

terjual

6 qty_on_hold INTEGER jumlah barang yang sudah dipesan

7 qty_re_order INTEGER Yes

jumlah barang yang harus dipesan

jika mencapai batas minimal

8 init_cost DOUBLE Yes

harga awal pembelian pertama (dari

PO id= 1)

9 high_cost DOUBLE harga pembelian tertinggi

10 low_cost DOUBLE harga pembelian terendah

11 average_cost DOUBLE harga pembelian rata-rata

12 diff_avrg_cost DOUBLE selisih harga pembelian rata-rata

13 closing_bal DOUBLE harga tutup buku pada akhir bulan

14 closing_avrg_cost DOUBLE

harga rata-rata saat tutup buku pada

akhir bulan

15 closing_diff_avrg_cost DOUBLE

selisih harga rata-rata saat tutup buku

pada akhir bulan

16 sell_fix_price DOUBLE harga penjualan fix

17 sell_latest_cost DOUBLE persentasi dari harga jual terakhir

18 sell_avrg_cost DOUBLE persentasi dari harga jual rata-rata

19 last_order_date DATETIME tanggal penjualan terakhir

20 last_issue_date DATETIME tanggal pembelian terakhir


22 update_date DATETIME tanggal terakhir melakukan update

23 latest_cost_final DOUBLE harga pembelian terakhir

24 latest_cost_second DOUBLE harga pembeliah 2 kali sebelumnya

25 latest_cost_init DOUBLE harga pembelian 1 kali sebelumnya

26 attach LONGBLOB foto

27 id_ad_warehouse BIGINT(20) Yes fk dari tabel warehouse

28 id_in_prod_brand BIGINT(20) Yes fk dari tabel prod_brand

29 id_in_prod_cat BIGINT(20) Yes fk dari tabel prod_cat

30 id_gl_acc BIGINT(20) Yes fk dari tabel general_ledger

31 id_ad_user BIGINT(20) Yes fk dari user

32 id_ad_uom BIGINT(20) Yes

fk tabel uom, satuan untuk harga beli

yang masuk ke gudang

33 in_status VARCHAR(255) Yes status tabel ("active", "inactive")

40

Nama tabel : IN_PROD_BRAND


1 id BIGINT yes

(PK) id untuk tabel

IN_PROD_BRAND

2 brand_desc VARCHAR(255) yes deskripsi dari brand produk

3 brand_status VARCHAR(255) yes status brand produk



Nama tabel : IN_PROD_CAT


1 id BIGINT yes id untuk tabel IN_PROD_CAT

2 prod_cat_desc VARCHAR(255) yes deskripsi dari kategori produk

3 prod_cat_status VARCHAR(255) yes status kategori produk



Nama tabel : IN_GOODS_RECEIVE



2 gooods_receive_code VARCHAR(255) yes kode setiap transaksi goods receive

3 transaction_code DATETIME yes tanggal transaksi goods receive


6 delivery_address VARCHAR(255) yes alamat pengiriman barang


8 id_pu_Rfq BIGINT(20) yes FK dari tabel pu_rfq




12 acc_year INTEGER tutup buku transaksi DO setiap bulan

13 acc_month INTEGER tutup buku transaksi DO setiap tahun

Nama tabel : IN_GOODS_RECEIVE_DETAIL


1 id BIGINT(20) yes id tabel pu_goods_receive_detail




5 id_in_goods_receive BIGINT(20) yes FK dari tabel pu_demand




41

Nama tabel : IN_MONTHEND_ITEM


1 id_in_item BIGINT(20) yes id untuk tabel in_monthend_item

2 acc_month INTEGER yes tutup buku inventory item setiap bulan

3 acc_year INTEGER yes tutup buku inventory item setiap tahun

4 quantity INTEGER yes banyak nya barang / item

5 avrg_cost DOUBLE yes harga rata-rata per item





e. Modul Order

Nama tabel : OR_SHIPPING_TYPE


1 id BIGINT Yes autoincrement

2 description VARCHAR Yes jenis pengirimannya



Nama tabel : OR_PAYMENT_TYPE


1 id BIGINT Yes autoincrement

2 description VARCHAR yes jenis pembayaran



Nama tabel : OR_CART


1 id BIGINT(20) Yes id untuk tabel or_cart

2 cart_code VARCHAR(255) yes kode penjualan

3 Shipping_type_id VARCHAR(255) yes Tipe pengiriman barang

4 id_or_debitur BIGINT(20) yes identitas yang pembeli

5 payment_type_id BIGINT(20) yes Tipe pembayaran

6 status VARCHAR(255) yes status transaksi cart("sent","draft","cancel")

7 reference_id VARCHAR(255) yes reference id untuk konfirmasi pembayaran



10 amount DOUBLE yes total amount transaksi

42


11 id_ad_user BIGINT(20) yes fk dari tabel user

12 acc_month INTEGER yes tutup buku transaksi penjualan setiap bulan

13 acc_year INTEGER yes tutup buku transaksi penjualan setiap tahun

Nama tabel : OR_CART_DETAIL


1 id yes id untuk tabel or_cart_detail

3 Id_ tem VARCHAR(255) yes Item yang dibeli apa

4 Price DOUBLE yes Harga barang peritem

5 uom_id BIGINT(20) yes unit satuan per item

6 Quantity INTEGER yes Jumlah barang yang dibeli

4 id_gl_account BIGINT(20) yes FK dari tabel GL_acoount



Nama tabel : OR_DELIVERY


1 ID BIGINT(20) yes id untuk tabel or_delivery

2 delivery_date DATETIME yes tangggal pengiriman barang

3 reference_id VARCHAR(255) yes reference_id pembelian barang

4 id_ad_vehicle BIGINT(20) yes jenis angkutan yang digunakan

5 id_ad_uom BIGINT(20) yes satuan untuk muatan

6 load INTEGER yes muatan dari kendaraan pengangkut

7 id_or_debitur BIGINT(20) yes FK dari tabel or_debitur

8 driver VARCHAR(255) yes nama supir



Nama tabel : OR_MONTHEND_TRX


1 id BIGINT(20) yes id untuk tabel PU_month_end





6 acc_year INTEGER yes tutup buku proses month end setiap tahun

7 monthend_desc VARCHAR(255) deskripsi dari monthend





43




14 id_ad_uom BIGINT(20) yes FK dari tabel ad_uom untuk satuan tiap unit

15 status VARCHAR(255) yes status transaksi



f. Modul Account Payable

Nama tabel : AP_INVOICE


1 id BIGINT(20) yes id untuk tabel ap_invoice

2 invoice_code VARCHAR(255) yes kode transaksi invoice

3 inv_ref_code VARCHAR(255) yes kode referensi

4 inv_ref_date VARCHAR(255) yes tanggal referensi

5 amount DOUBLE yes total amount tagihan

6 id_pu_demand BIGINT(20) yes FK dari tabel pu_demand


8 acc_month INTEGER tutup buku proses month end setiap bulan

9 acc_year INTEGER tutup buku proses month end setiap tahun

10 status VARCHAR(255) yes status transaksi ("sent","draft","cancel")



Nama tabel : AP_INVOICE_DETAIL


1 id BIGINT(20) yes id untuk tabel ap_invoice_detail

2 id_ap_invoice BIGINT(20) yes Fk dari tabel ap_invoice

3 id_in_item BIGINT(20) yes FK dari tabel in_item

4 id_gl_acc BIGINT(20) yes FK dari tabel gl_acc

5 quantity INTEGER yes banyaknya barang

6 id_ad_uom DOUBLE yes FK dari tabel ad_uom

7 price DOUBLE yes harga satuan per item

8 status VARCHAR(255) yes status tabel ("active","inactive")



Nama tabel : AP_MONTHEND


1 id BIGINT(20) yes id untuk tabel AP_month_end


44





6 acc_year INTEGER yes tutup buku proses month end setiap tahun












Nama tabel : AP_PAYMENT


1 id BIGINT(20) Yes id untuk tabel ap_payment

2 payment_code VARCHAR(255) yes kode transaksi payment

3 inv_ref_code VARCHAR(255) yes kode referensi

4 inv_ref_date VARCHAR(255) yes tanggal referensi

5 amount DOUBLE yes total amount pembayaran







Nama tabel : AP_PAYMENT_DETAIL


1 id BIGINT(20) yes id untuk tabel ap_invoice_detail

2 id_ap_payment BIGINT(20) yes Fk dari tabel ap_payment



5 id_ap_invoice BIGINT(20) yes Fk dari tabel ap_invoice

6 id_month_end BIGINT(20) yes FK dari tabel month_end




45

g. Modul Account Receivable

Nama tabel : AR_INVOICE


1 id BIGINT(20) yes id untuk tabel ap_invoice

2 invoice_code VARCHAR(255) Yes kode transaksi invoice

3 amount DOUBLE yes total amount tagihan


5 id_or_cart BIGINT(20) FK dari tabel or_cart






Nama tabel : AR_INVOICE_DETAIL


1 id BIGINT(20) yes id untuk tabel ar_invoice_detail

2 id_ar_invoice BIGINT(20) yes Fk dari tabel ar_invoice



5 quantity INTEGER yes banyaknya barang

6 id_ad_uom DOUBLE yes FK dari tabel ad_uom

7 price DOUBLE yes harga satuan per item




Nama tabel : AR_MONTHEND


1 id BIGINT(20) yes id untuk tabel Ar_month_end




5 acc_month INTEGER yes tutup buku proses monthend setiap bulan

6 acc_year INTEGER yes tutup buku proses monthend setiap tahun







46







Nama tabel : AR_RECEIPT


1 id BIGINT(20) Yes id untuk tabel ap_payment

2 payment_code VARCHAR(255) yes kode transaksi payment


4 amount DOUBLE yes total amount pembayaran






Nama tabel : AR_RECEIPT_DETAIL


1 id BIGINT(20) yes id untuk tabel ar_invoice_detail

2 id_ar_receipt BIGINT(20) yes Fk dari tabel ar_receipt



5 id_ar_invoice BIGINT(20) yes Fk dari tabel ar_invoice




Lampiran 5 Teknik Inversion of Controls pada pembuatan objek dataSource dan

sessionFactory dan dimasukan ke semua DAO untuk melakukan akses data

a. membuat dataSource dari properi basis data

<bean

id="dataSource"

class="org.springframework.jdbc.datasource.

DriverManagerDataSource">

<property name="username" value="${jdbc.username}"/>

<property name="password" value="${jdbc.password}"/>

<property name="url" value="${jdbc.url}"/>

<property name="driverClassName" value="${jdbc.driver}"/>

</bean>

47

b. membuat sessionFactory dari dataSource dan DTO

<bean

id="sessionFactory"

class="org.springframework.orm.hibernate3.annotation.

AnnotationSessionFactoryBean">

<property name="dataSource" ref="dataSource"/>

<property name="annotatedClasses">

<list>



<value>ilkom.erp.inventory.InventoryItem</value>

<value>ilkom.erp.inventory.InventoryProductBrand</value>

<value>ilkom.erp.inventory.InventoryProductCategory</value>

<value>ilkom.erp.inventory.InventoryGoodReceive</value>

<value>ilkom.erp.inventory.InventoryGoodReceiveDetail</value>

<value>ilkom.erp.inventory.InventoryMonthenditem</value>



<value>ilkom.erp.purchase.PurchaseSupplier</value>

<value>ilkom.erp.purchase.PurchaseRequisition</value>

<value>ilkom.erp.purchase.PurchaseRequisitionDetail</value>

<value>ilkom.erp.purchase.PurchaseSupplyRFQ</value>

<value>ilkom.erp.purchase.PurchaseSupplyRFQDetail</value>

<value>ilkom.erp.purchase.PurchaseRFQPrice</value>

<value>ilkom.erp.purchase.PurchaseDemand</value>

<value>ilkom.erp.purchase.PurchaseDemandDetail</value>

<value>ilkom.erp.purchase.PurchaseOrder</value>

<value>ilkom.erp.purchase.PurchaseOrderDetail</value>

<value>ilkom.erp.purchase.PurchaseMonthendtrx</value>



<value>ilkom.erp.generalLedger.GeneralLedgerAccount</value>

<value>ilkom.erp.generalLedger.GLJournal</value>

<value>ilkom.erp.generalLedger.GLJournalDetail</value>

<value>ilkom.erp.generalLedger.GLMonthEnd</value>



<value>ilkom.erp.order.OrderDebitur</value>

<value>ilkom.erp.order.OrderCart</value>

<value>ilkom.erp.order.OrderCartDetail</value>

<value>ilkom.erp.order.OrderShippingType</value>

<value>ilkom.erp.order.OrderPaymentType</value>

<value>ilkom.erp.order.OrderDelivery</value>

<value>ilkom.erp.order.OrderMonthendtrx</value>



<value>ilkom.erp.admin.AdminAccPeriod</value>

<value>ilkom.erp.admin.AdminCompany</value>

<value>ilkom.erp.admin.AdminGroup</value>

<value>ilkom.erp.admin.AdminModul</value>

<value>ilkom.erp.admin.AdminUOM</value>

<value>ilkom.erp.admin.AdminUOMConvertion</value>

<value>ilkom.erp.admin.AdminUser</value>

<value>ilkom.erp.admin.AdminVehicle</value>

<value>ilkom.erp.admin.AdminPage</value>

<value>ilkom.erp.admin.AdminModulPeriod</value>



<value>ilkom.erp.accountReceivable.AccountReceivableInvoice</value>

<value>ilkom.erp.accountReceivable.AccountReceivableInvoiceDetail</value>

<value>ilkom.erp.accountReceivable.AccountReceivableReceipt</value>

<value>ilkom.erp.accountReceivable.AccountReceivableReceiptDetail</value>

<value>ilkom.erp.accountReceivable.AccountReceivableMonthEnd</value>

<!—accountPayable-->

<value>ilkom.erp.accountPayable.AccountPayableInvoice</value>

<value>ilkom.erp.accountPayable.AccountPayableInvoiceDetail</value>

<value>ilkom.erp.accountPayable.AccountPayablePayment</value>

<value>ilkom.erp.accountPayable.AccountPayablePaymentDetail</value>

<value>ilkom.erp.accountPayable.AccountPayableMonthEnd</value>

</list>

</property>

48

c. memasukan objek sessionFactory ke semua DAO

<!—inventoryDao-->

<bean

id="inventoryItemDao" class="ilkom.erp.inventory.dao.hibernate.

InventoryItemDaoHibernate">

property name="sessionFactory" ref="sessionFactory"/></bean>

<bean

id="inventoryProductBrandDao" class="ilkom.erp.inventory.dao.hibernate.

InventoryProductBrandDaoHibernate">

<property name="sessionFactory" ref="sessionFactory"/></bean>

<bean

id="inventoryProductCategoryDao" class="ilkom.erp.inventory.dao.hibernate.

InventoryProductCategoryDaoHibernate">


<bean

id="inventoryGoodReceiveDao" class="ilkom.erp.inventory.dao.hibernate.

InventoryGoodReceiveDaoHibernate">


<bean

id="inventoryGoodReceiveDetailDao" class="ilkom.erp.inventory.dao.hibernate.

InventoryGoodReceiveDetailDaoHibernate">


<bean

id="inventoryMonthenditemDao" class="ilkom.erp.inventory.dao.hibernate.

InventoryMonthenditemDaoHibernate">




<bean

id="purchaseSupplierDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseSupplierDaoHibernate">


<bean

id="purchaseRequisitionDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseRequisitionDaoHibernate">


<bean

id="purchaseRequisitionDetailDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseRequisitionDetailDaoHibernate">


<bean

id="purchaseSupplyRFQDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseSupplyRFQDaoHibernate">


<bean

id="purchaseSupplyRFQDetailDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseSupplyRFQDetailDaoHibernate">


<bean

id="purchaseDemandDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseDemandDaoHibernate">


<bean

id="purchaseDemandDetailDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseDemandDetailDaoHibernate">


<bean

id="purchaseOrderDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseOrderDaoHibernate">

49


<bean

id="purchaseOrderDetailDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseOrderDetailDaoHibernate">


<bean

id="purchaseMonthendtrxDao" class="ilkom.erp.purchase.dao.hibernate.

PurchaseMonthendtrxDaoHibernate">




<bean

id="generalLedgerDao" class="ilkom.erp.generalLedger.dao.hibernate.

GeneralLedgerDaoHibernate">


<bean

id="gLJournalDao" class="ilkom.erp.generalLedger.dao.hibernate.

GLJournalDaoHibernate">


<bean

id="gLJournalDetailDao" class="ilkom.erp.generalLedger.dao.hibernate.

GLJournalDetailDaoHibernate">


<bean

id="gLMonthEndDao" class="ilkom.erp.generalLedger.dao.hibernate.

GLMonthEndDaoHibernate">




<bean

id="orderDebiturDao" class="ilkom.erp.order.dao.hibernate.

OrderDebiturDaoHibernate">


<bean

id="orderCartDao" class="ilkom.erp.order.dao.hibernate.

OrderCartDaoHibernate">


<bean

id="orderCartDetailDao" class="ilkom.erp.order.dao.hibernate.

OrderCartDetailDaoHibernate">


<bean

id="orderShippingTypeDao" class="ilkom.erp.order.dao.hibernate.

OrderShippingTypeDaoHibernate">


<bean

id="orderPaymentTypeDao" class="ilkom.erp.order.dao.hibernate.

OrderPaymentTypeDaoHibernate">


<bean

id="orderDeliveryDao" class="ilkom.erp.order.dao.hibernate.

OrderDeliveryDaoHibernate">


<bean

id="orderMonthendtrxDao" class="ilkom.erp.order.dao.hibernate.

OrderMonthendtrxDaoHibernate">




<bean

id="adminAccPeriodDao" class="ilkom.erp.admin.dao.hibernate.

AdminAccPeriodDaoHibernate">

50

<bean

id="adminCompanyDao" class="ilkom.erp.admin.dao.hibernate.

AdminCompanyDaoHibernate">


<bean

id="adminGroupDao" class="ilkom.erp.admin.dao.hibernate.

AdminGroupDaoHibernate">


<bean

id="adminModulDao" class="ilkom.erp.admin.dao.hibernate.

AdminModulDaoHibernate">


<bean

id="adminUOMConvertionDao" class="ilkom.erp.admin.dao.hibernate.

AdminUOMConvertionDaoHibernate">


<bean

id="adminUOMDao" class="ilkom.erp.admin.dao.hibernate.

AdminUOMDaoHibernate">


<bean

id="adminUserDao" class="ilkom.erp.admin.dao.hibernate.

AdminUserDaoHibernate">


<bean

id="adminVehicleDao" class="ilkom.erp.admin.dao.hibernate.

AdminVehicleDaoHibernate">


<bean

id="adminPageDao" class="ilkom.erp.admin.dao.hibernate.

AdminPageDaoHibernate">


<bean

id="adminModulPeriodDao" class="ilkom.erp.admin.dao.hibernate.

AdminModulPeriodDaoHibernate">




<bean

id="accountReceivableInvoiceDao" class="ilkom.erp.accountReceivable.dao.hibernate.

AccountReceivableInvoiceDaoHibernate">


<bean

id="accountReceivableInvoiceDetailDao"

class="ilkom.erp.accountReceivable.dao.hibernate.

AccountReceivableInvoiceDetailDaoHibernate">


<bean

id="accountReceivableReceiptDao" class="ilkom.erp.accountReceivable.dao.hibernate.

AccountReceivableReceiptDaoHibernate">


<bean

id="accountReceivableReceiptDetailDao"


AccountReceivableReceiptDetailDaoHibernate">


<bean

id="accountReceivableMonthEndDao"


AccountReceivableMonthEndDaoHibernate">

51



<bean

id="accountPayableInvoiceDao" class="ilkom.erp.accountPayable.dao.hibernate.

AccountPayableInvoiceDaoHibernate">


<bean

id="accountPayableInvoiceDetailDao" class="ilkom.erp.accountPayable.dao.hibernate.

AccountPayableInvoiceDetailDaoHibernate">


<bean

id="accountPayablePaymentDao" class="ilkom.erp.accountPayable.dao.hibernate.

AccountPayablePaymentDaoHibernate">


<bean

id="accountPayablePaymentDetailDao" class="ilkom.erp.accountPayable.dao.hibernate.

AccountPayablePaymentDetailDaoHibernate">


<bean

id="accountPayableMonthEndDao" class="ilkom.erp.accountPayable.dao.hibernate.

AccountPayableMonthEndDaoHibernate">


d. memasukan semua DAO ke dalam masing-masng Service sesuai dengan submodulnya

<bean

id="inventoryService" class="ilkom.erp.service.impl.InventoryServiceImpl">

<property

name="inventoryItemDao"

ref="inventoryItemDao"/>

<property

name="inventoryProductBrandDao"

ref="inventoryProductBrandDao"/>

<property

name="inventoryProductCategoryDao"

ref="inventoryProductCategoryDao"/>

<property

name="inventoryGoodReceiveDao"

ref="inventoryGoodReceiveDao"/>

<property

name="inventoryGoodReceiveDetailDao" ref="inventoryGoodReceiveDetailDao"/>

<property

name="inventoryMonthenditemDao"

ref="inventoryMonthenditemDao"/>

</bean>



<bean

id="purchaseService" class="ilkom.erp.service.impl.PurchaseServiceImpl">

<property

name="purchaseSupplierDao"

ref="purchaseSupplierDao"/>

<property

name="purchaseRequisitionDao"

ref="purchaseRequisitionDao"/>

<property

name="purchaseRequisitionDetailDao" ref="purchaseRequisitionDetailDao"/>

<property

name="purchaseSupplyRFQDao"

ref="purchaseSupplyRFQDao"/>

<property

name="purchaseSupplyRFQDetailDao" ref="purchaseSupplyRFQDetailDao"/>

<property

name="purchaseDemandDao"

ref="purchaseDemandDao"/>

52

<property

name="purchaseDemandDetailDao"

ref="purchaseDemandDetailDao"/>

<property

name="purchaseOrderDao"

ref="purchaseOrderDao"/>

<property

name="purchaseOrderDetailDao"

ref="purchaseOrderDetailDao"/>

<property

name="purchaseMonthendtrxDao"

ref="purchaseMonthendtrxDao"/>

<property

name="inventoryItemDao"

ref="inventoryItemDao"/>

</bean>



<bean

id="generalLedgerService" class="ilkom.erp.service.impl.GeneralLedgerServiceImpl">

<property name="generalLedgerDao" ref="generalLedgerDao"/>

<property name="GLJournalDao" ref="gLJournalDao"/>

<property name="GLJournalDetailDao" ref="gLJournalDetailDao"/>

<property name="GLMonthEndDao" ref="gLMonthEndDao"/>

</bean>



<bean

id="orderService" class="ilkom.erp.service.impl.OrderServiceImpl">

<property name="orderDebiturDao" ref="orderDebiturDao"/>

<property name="orderCartDao" ref="orderCartDao"/>

<property name="orderCartDetailDao" ref="orderCartDetailDao"/>

<property name="orderShippingTypeDao" ref="orderShippingTypeDao"/>

<property name="orderPaymentTypeDao" ref="orderPaymentTypeDao"/>

<property name="orderDeliveryDao" ref="orderDeliveryDao"/>

<property name="orderMonthendtrxDao" ref="orderMonthendtrxDao"/>

</bean>



<bean

id="adminService" class="ilkom.erp.service.impl.AdminServiceImpl">

<property name="adminAccPeriodDao" ref="adminAccPeriodDao" />

<property name="adminCompanyDao" ref="adminCompanyDao"/>

<property name="adminGroupDao" ref="adminGroupDao"/>

<property name="adminModulDao" ref="adminModulDao"/>

<property

name="adminUOMConvertionDao"

ref="adminUOMConvertionDao"/>

<property name="adminUOMDao" ref="adminUOMDao"/>

<property name="adminUserDao" ref="adminUserDao"/>

<property name="adminVehicleDao" ref="adminVehicleDao"/>

<property name="adminPageDao" ref="adminPageDao"/>

<property name="adminModulPeriodDao" ref="adminModulPeriodDao"/>

</bean>


<bean

id="accountReceivableService"

class="ilkom.erp.service.impl.AccountReceivableServiceImpl">

<property

name="accountReceivableInvoiceDao" ref="accountReceivableInvoiceDao"/>

<property

name="accountReceivableInvoiceDetailDao" ref="accountReceivableInvoiceDetailDao"/>

<property

name="accountReceivableReceiptDao" ref="accountReceivableReceiptDao"/>

<property

name="accountReceivableReceiptDetailDao" ref="accountReceivableReceiptDetailDao"/>

<property

name="accountReceivableMonthEndDao" ref="accountReceivableMonthEndDao"/>

</bean>



<bean

53

id="accountPayableService"

class="ilkom.erp.service.impl.AccountPayableServiceImpl">

<property

name="accountPayableInvoiceDao"

ref="accountPayableInvoiceDao"/>

<property

name="accountPayableInvoiceDetailDao" ref="accountPayableInvoiceDetailDao"/>

<property

name="accountPayablePaymentDao"

ref="accountPayablePaymentDao"/>

<property

name="accountPayablePaymentDetailDao" ref="accountPayablePaymentDetailDao"/>

<property

name="accountPayableMonthEndDao"

ref="accountPayableMonthEndDao"/>

</bean>

Lampiran 6 Declarative Transaction untuk setiap modul

<!—Inventory-->

<bean

id="moduleInventoryService" class="org.springframework.transaction.interceptor.

TransactionProxyFactoryBean">

<property name="target" ref="inventoryService"/>

<property name="transactionManager" ref="hibernateTransactionManager"/>

<property name="transactionAttributes">

<props>

<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>

<prop key="save*">PROPAGATION_REQUIRED</prop>

<prop key="delete*">PROPAGATION_REQUIRED</prop>

</props>

</property>

</bean>



<bean

id="modulePurchaseService" class="org.springframework.transaction.interceptor.


<property name="target" ref="purchaseService"/>



<props>




</props>

</property>

</bean>



<bean

id="moduleGeneralLedgerService"

class="org.springframework.transaction.interceptor.


<property name="target" ref="generalLedgerService"/>



<props>




</props>

</property>

</bean>



<bean

id="moduleOrderService" class="org.springframework.transaction.interceptor.


<property name="target" ref="orderService"/>



<props>

54




</props>

</property>

</bean>



<bean

id="moduleAdminService" class="org.springframework.transaction.interceptor.


<property name="target" ref="adminService"/>



<props>




</props>

</property>

</bean>


<bean

id="moduleAccountReceivableService"



<property name="target" ref="accountReceivableService"/>



<props>




</props>

</property>

</bean>



<bean

id="moduleAccountPayableService"



<property name="target" ref="accountPayableService"/>



<props>




</props>

</property>

</bean>

Lampiran 7 contoh kode program

a. tanpa menggunakan ORM

public class UserDaoSql92 implements UserDao {

private DataSource dataSource;

private PreparedStatement insertStatement;

private PreparedStatement updateStatement;

private PreparedStatement deleteStatement;

public UserDaoSql92(DataSource dataSource) throws DaoException {

try {

this.dataSource = dataSource;

java.sql.Connection conn = this.dataSource.getConnection();

insertStatement = conn.prepareStatement

("insert into USER(user_name, password, email ) values (?, ? ,?)");

55

updateStatement = conn.prepareStatement

("update USER set (user_name=?, password=?, email=? )");

deleteStatement = conn.prepareStatement("delete USER where user_id=?");

} catch (SQLException ex) {

Logger.getLogger("global").log(Level.SEVERE, null, ex);

}

}

public void create(User user) throws DaoException {

if (user == null) {

throw new struts.dao.exception.DaoException("insert null user");

} else {

User usr = getById(user.getUserId());

if (user.getUserId() != 0 && usr != null) {

throw new DuplicateNameException();

} else {

try {

insertStatement.setString(1, user.getUserName());

insertStatement.setString(2, user.getPassword());

insertStatement.setString(3, user.getEmail());

insertStatement.executeUpdate()

} catch (SQLException ex) {

Logger.getLogger("global").log(Level.SEVERE, null, ex);

}

}

b. Dengan ORM tanpa Declarative Transaction dan Inversion of Controls

public class UserDaoHibernate{

public void insert (User user){

Configuration cfg = new Configuration();

SessionFactory factory = cfg.configure().buildSessionFactory();

Session session = factory.openSession();

User user= new User();

user.setName("Dianis");

user.setEmail("[email protected]");

user.setPassword("rahasia")

session.save(user);

session.flush();

session.close();

}

public void update (Long userId){




Transaction transaction = session.beginTransaction();

Long userId = 1l;

USer user= (User) session.load(User.class, userId);

System.out.println(user.getName());

user.setName("indah");

session.update(user);

transaction.commit();

session.close();

}

public void delete(Long userId){




Transaction transaction = session.beginTransaction();

Long userId = 1l;

user user = (user) session.load(user.class, userId);

System.out.println(user.getName());

session.delete(user);

transaction.commit();

session.close();

}

}

56

c. Dengan ORM, Declarative Transaction, dan Inversion of Controls

public class UserDaoHibernate extends HibernateDaoSupport implements UserDao {

public void save(User user) {

getHibernateTemplate().saveOrUpdate(user);

}

public void delete(User user) {

getHibernateTemplate().delete(user);

}

}

penerapan object relational mapping pada pengembangan ... · pengguna linux indonesia-bogor) ......

Documents