DIAN INDAH SAVITRI
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
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
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
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.
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
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
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 danJEE 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
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
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 dari penelitian ini adalah: 1 Menganalisis ketidaksesuaian yang
muncul dari rancangan sistem RitelERP 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
(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).
PersistentObject
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
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
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
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
frameworkopen 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
Table3
OR
M
ap
pin
Controller
Model View
Manipulasi Interaksi
Ditampilkan 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 terujidalam 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
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 iniberfungsimengatur 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
Studi literatur
Analisis permasalahan ketidaksesuaian
Perancangan dan implementasi ORM
dan design pattern
evaluasi
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 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
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
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.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:
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
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:
-
ClassSupplier1 @Entity
2 @Table(name = "PU_SUPLIER") 3 public class Supplier{ 4 @Embedded
5 private Address address = new 6 Address();
7 }
- ClassAddress
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
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
Demand yang berasosiasi one-to-one dengan
class Order. Letak foreign key atau join column ditambahkan pada entitas yang mempunyai totalparticipation pada asosiasi yang menghubungkannya.
Pada entitas yang mempunyai asosiasi dua arah (bidirectional) diperlukan penambahan properti mappedBy oleh entitas yang tidak totalparticipation (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 }
- ClassDemand
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.
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 totalparticipation. 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:
-
ClassRequisitionDetail1 @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
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:
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 }
-
ClassModul1 @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 totalparticipation
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
getter. Contoh:
-
ClassItem1 @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:
- ClassBrand
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.
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
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 dilihat pada Lampiran 5.
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);
} }
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.
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.
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
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.
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 dilihat pada Lampiran 7.
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
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).
DAFTARPUSTAKA
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.
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.
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
no Nama tabel keterangan
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
no Nama tabel keterangan
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
no Nama tabel keterangan
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
no Nama tabel keterangan
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
no Nama tabel keterangan
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
no Nama tabel keterangan
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
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 -supplier : Supplier
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 * -invoiceDetail 1 -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 -uom 1
-id : Long -code : String -amount : Double -accYear : Integer -accMonth : Integer -status : String -createDate : Date -updateDate : Date -supplier : Supplier
Payment
-id : Long -amount : Double -status : String -createDae : Date -updateDate : Date -payment : Payment -invoice : Invoice -acc : Account -monthEnd : MonthEnd
PaymentDetail -payment
1 -supplier* -payment1* -paymentDetail
-paymentDetail 1 -acc 1 -monthEnd 1 -paymentDetail * -paymentDetail 1 -invoice 1
Lampiran 2 Class Diagram Data Transfer Object
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 -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 : D
