HASIL DAN PEMBAHASAN Analisis Permasalahan Ketidaksesuaian 1 Deskripsi Umum Aplikasi Ritel ERP a Granularity b Identitas

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.

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.

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:

-

ClassSupplier

1 @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

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

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 }

- 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.

 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:

-

ClassRequisitionDetail

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

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. Jointabel 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

lain bisa langsung menggunakan method getter. Contoh:

-

ClassItem

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:

- 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.

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

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 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);

} }

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,

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

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 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

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.